Gruntle Enterprise

i am happy to announce that we have reached our first milestone in developing the Bodhi CMS. what we set out to accomplish was to develop a content management system that would allow us to quickly and easily manage a website. the goal in the beginning was to use the product in-house for our client projects, providing a stable base upon which we can build websites to our client's specifications. as it is used in-house right now, all of the bells and whistle are not in place, but the fundamental architecture and framework is ready, which means that the next step is to integrate dynamic interface design based on ajax libraries that are freely available and in wide use. here is a brief summary of the basic architecture and how each elements works in concert with the whole. for now, i will leave out any mention of those django modules with which our CMS interacts. needless to say, we rely on the auth module to control who has access to the backoffice editor. lastly, i have already addressed in [previous posts](/iris/blog/2006/jul/21/database-template-loader-and-template-tags/) the concept of our template loader that uses a database as the source for template layouts in previous posts. suffice it to say, this was a key component in making the CMS flexible and easy to use. all design and structure is controled via the backoffice editor, which means you control virtually all elements of the site via your browser. of course, you also have the option of using templates from the file system, which we do for the blog for example. whatever you website requirements, you decide how to control content management from the template level. **Overview** basically, in the worldview of our CMS, there are four elements that work together to make up a site: - Layouts - Pages - Page Parts - Snippets from the top down, you have your layout, which is the foundation upon which you build your UI. we gain many useful features from django in this respect. for example, your base layout can control the entire site and all of your pages "extend" that base layout. that is, they are based upon the core design of base. and you can as many base layouts as you have sections, if you like. next you have your pages. for each page, you can choose your layout. most import to note at this point, are the Parent id and Path fields. your home page will not have a parent id, since it is at the top of the hierarchy, but its path will always be "/". an about page, would probably have home as its parent and a path of "about/". further, a staff page would have "about" as its parent and a path of "about/staff/". and so on. at the moment, the user must manage the consistency between parent and path, but in future releases, once you choose your parent, you would get the root path supplied in the path field, so that you would only need to provide the remainder of the path, which would coincide somehow with the page title. ideally, you might even have the path completed once you provided a title and parent. in terms of the page parts, at the moment, we only have one page part, the body. the system is designed to have as many page parts as you want, but for now only the body was needed. when you use the backoffice editor, you really do not see the separation between page and page parts at this point. you simply create the page and the system updates the page and page part models. lastly, there is the concept of code "snippets". these are reusable bits that can be used throughout the site. for example, we have header and footer snippets, which can be used in any layout you create to provide a consistent container for these elements across disparate sections. we also created a "sidebar" snippet, which provides navigation throughout the site. these snippets are made available to the templates through custom templatetags, a django feature for creating custom tags that can access data objects and provide a means for displaying data from your database in the template system. combined with the concept of "blocks" inherent to django templates, you now have a powerful way of managing the key UI elements of your site. for example, in your base template, you might have a block called "sidebar", which in your base template contains your global nav snippet. in any templates that extend your base template, you can include your "sidebar" block and grab a different sidebar snippet for your navigation, or whatever you want to publish there. in short, you can now control all elements of a website with ease and speed. you can use the [xinha](/iris/blog/2006/jul/20/xinha-textarea-editor/) wysiwyg rich text editor if you like or work directly with HTML source. with xinha, you can add images to your content, but at the moment this requires you to provide a fully qualified URL to the image, rather than uploading an image and managing it from the server itself. xinha has this feature, but requires PHP and i have not integrated the django with PHP just yet. anyway, i look forward to your feedback. understand, however, that the application is very rough. i have attempted to simply provide all of the functionality available to us, and did not concern myself much with design and user experience. as i use the application, i come across things that i do not like and i try to improve upon the UE when i can, since that sometimes highlights flaws in the architecture, so feel free to point out those UI issues that might underlie fundamental flaws in the system. 0 Comments, 0 trackbacks (Trackback URL)