We are passing by the controller-action-view chain in the development process and are moving on to display mechanisms that will render pages and page components.
During these 7 years that I’ve been producing community software there were two main requirements: robustness and insane flexibility. OpenWack as an open source social networking software is not an exception. We defined several important points that OpenWack theming must meet:
- Speed and easiness of creating new themes
- Easiness of maintaining and upgrading themes
- Easiness of maintaining integrated look’n'feel throughout the vast 3rd party functionality
For display customization tools:
- Possibility to move around elements within and between pages
- Possibility to add custom pages with custom and existing elements from plugins.
- Possibility to edit existing pages (even created by plugins) and add custom and existing elements from other plugins
Our team has intense discussions at what theming and customization approach would be sufficient for open source software with an unlimited range of functionality.
We have a serious task of dividing the markup and styles of everything into independent and mobile pieces to get the right balance of flexibility and ease of creation and maintenance.
Here is the descending chain of information display that needs to be customized at each node:
Main CSS -> Masterpage -> Page template -> Component -> Decorator
1) Main CSS
This is the main CSS stylesheet provided by a theme. It implements general styles for colors, fonts, graphics, buttons and all general website elements.
2) Masterpages
These are markup patterns also implemented by a theme. For example, your site has standard header, footer, and sidebar while your index page is custom – has no sidebar and its header contains promotional graphics and banners. Here you have 2 masterpages (e.g. “general” and “index”) that will serve as envelopes with a big white hole instead of the actual page content.
3) Page templates
They are a number of standard page layouts implemented by OpenWack core and plugins that describe sectioned markup with components that the page contains.
Here’s an example of markup for a page template of 2 columns with a list of new members and a welcome message (Warning: Actual OpenWack code may be different.)
<div class="left supernarrow small stdmargin">
{component type="latest_members" decorator="list_picture_content" data=$latest_members_data}
</div>
<div class="right superwide stdmargin">
{component type="message" data=$welcome_message}
</div>
This is a page template for site index page. Mailbox or forum topic page will have different layout and different components on them. You can edit templates of the custom pages you create and also pages that are created by plugins. Put an invitation box for the upcoming community event on photo list page so nobody misses.
4) Components
Components (as shown in Page templates section) are obejcts that show pieces of information all over the place on your site. All pages can be seen as placeholders of components of different purpose (comment list, input form, latest photos, mailbox message, etc…) and look (boxes, highlighted boxes, images, pieces of text, list of images, controls and inputs). Components are created by core, by plugins, and some basic ones (text, image, RSS) by site editors.
5) Decorators
Decorators are mainly templates for components with specific CSS and JavaScript. Every component must use a decorator, and different components can use one decorator as a way to display content. Recent blog posts, video and photo comments, a list of latest forum topics will all use one decorator that will display a profile avatar, header information (e.g. post title), and content.
Thus a number of decorators (around 20) will be provided by the core for hundreds of possible components implemented by tens of possible plugins. Sure there will be a moment when none of the existing decorators will fit your custom component – feel free to create your own with a template, CSS, and JavaScript. This is why decorators must be independent and mobile.
Each theme can override default decorator markup, so by creating new decorator templates you can customize your theme so nobody even recognizes OpenWack software behind your site. And this is as easy as creating several decorator templates with little amount of markup.
CSS styling of decorators should of course comply with the main theme CSS to just add customized elements or override some of the standard ones, not describe decorators from scratch. Since decorators are universal and can be created by plugins without theme context
they should maintain a good standard of markup and CSS compliance. Careful creating new decorators means better display and easiness of theme mantenance.
Conclusion
With this chain of customizable nodes descending from pages to the basic bits of information displayed on your site you have the benefit of integrated look’n'feel throughout the site (done by using a few decorators by all components); you can create themes that will be sufficient for all existing and future plugins (if they use best practices); you can quickly and easily clone an existing theme and change it upside down by playing with main CSS stylesheet, masterpages and decorators markup.
We hope this approach is going to provide easy and quick way to create maintainable themes while not sacrificing the flexibility and freedom of content and design. If you have any feedback on the offered model feel free to comment and share your ideas.
P.S. Ah, I forgot to add that we need to make it possible to do all this customization via admin panel, without messing with files, because we need to give WackWall free social networks the same level of control. Didn’t I mention that our mission is difficult and interesting? ;)
We are in the process of the OpenWack development. For those who don’t know 
Recent Comments