Proposal and design
The purpose of the project is to add a mobile theme capability to Roller and at least one mobile theme. The project design was started on the Roller wiki. Here is the proposal:
The design's evolution is documented on the Roller mailing list and via a series of blog entries. Below is a list, with links, of each of the blog entries so far and my summary of the changes discussed.
Blog: Mobile Theme setting up and its Use Cases
- UI change - admin must pick mobile theme
- New Weblog property - defaultMobileTheme
- Rendering change - PageServlet sets weblog.editorTheme
Blog: Adding Meta-data in theme.xml
- New theme meta-data value - type in theme.xml
Blog: Tag to define template type in theme.xml
- Type values: standard, mobile
Blog: Creating custom template
- Change to template management
- Each template has a standard and a mobile parts
Blog: Editing templates
- Change to template UI
Blog: Changing Mobile Theme template
- Design for selecting mobile theme vs. standard theme
Implementation started well and made good progress. Below is a list of the changes, grouped into related blocks and AFTER each block, a comment about the changes.
Those changes add a new property named type to themes and to templates. So far so good.
That change adds mobile device detection. Good.
Beginnings of a mobile theme. Good.
Here we add a new column "mobilethemename" to the table "weblog." This could be viewed as a problem because there may be more types of themes in the future, e.g. touch screen, TV set-top box, etc. and we don't want to have to add a new column to the weblog table every time we add one.
These changes add getEnabledStandardThemeList() and getEnabledMobleThemeList(). This could also be seen as a problem because it hardcodes the names of specific theme types into Java classes. It would be better to have one method with the signature:
This changes the getPageByLink() to getPagesByLink() which returns multiple pages, because different types of themes share the same link.
These changes modify the rendering Servlets to check the incoming request and to determine which type of theme and templates should be used to render the response.
These changes enable users to pick both a standard and mobile theme at theme creation time. Here are are "hardcoding" knowledge of the mobile theme type into the UI, which is not ideal but is hard to avoid without some serious UI design and dev work.
These changes make it so that, when a new template is created there are actually two templates that are created, one of type standard and one of type mobile. That means two records are created in the webpage template or each "template" created via the web UI.
Shelan has done a great job of seeking feedback and documenting his evolving design thoughts via the Roller mailing list and his blog. The proposal on the wiki is not as up to date and complete as it could be, but that could be fixed by deleting out of date material and perhaps, adding links to key design discussions on the mailing list.
Implementation has gone well so far, with lots of good progress, but there are two course corrections that should be made. First, as we discussed on the mailing list, we should avoid hard-coding mobile-specific fields into the database. Second, the design for storage of different type of templates seems too complex and introduces too many changes to Roller code. There are some recommended new designs below to adjust these problems.
Recommended design changes
These are recommended changes to the Roller Mobile design. First, a fix for the mobile-specific field in the Weblog object and corresponding website table. We want to allow each weblog to have a set of themes, each with a name so we introduce a WeblogThemeAssoc class and a corresponding rol_weblogtheme table like this:
Second, a new design for weblog templates. Instead of creating a WeblogTemplate for each type of template (e.g. standard, mobile, etc.), we allow each WeblogTemplate to have multiple "template code" objects. In effect, each WeblogTemplate object will have two WeblogTemplateCode objects, one for type standard and one for type mobile. With this approach, we shouldn't have to make as many changes to Roller code, especially in the Struts UI actions.