On 4/3/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
after spending a reasonable amount of time working on my various
proposals which are all related to weblog design and customization i
have found that our object model for themes is not as well constructed
as i think it should be. the relationship between static themes and
custom weblog themes is kind of duct taped together right now and i have
some ideas on how to improve it using just a bit of refactoring.
what i'd like to do is start by redefining a Theme as "The set of
elements used to render a weblog", and use that statement to define a
more appropriate object model for themes.
That seems too broad. How about: "the set of elements that define the
pages/feeds, styles and resources used to generate the web
representation of a weblog"
The idea is that the Theme object should be *the* object which is used to
access all information
about how a weblog design is defined. So instead of having the Theme
object just represent a static theme, like it does now, I'd like the
Theme object to be an interface which would have an implementation for
static (shared) themes and an implementation representing a custom
weblog theme. You then access the elements that make up the theme using
the Theme object. A Theme would contain all resources relevant to
weblog design, which currently means templates & files.
Sounds good and I agree themes should be encapsulated as objects and
treated more uniformly in our code whether they are custom or shared.
So, the updated object model would be structured basically like this ...
Theme (Interface)
+-- StaticTheme
+-- WeblogTheme
Template (Interface)
+-- ThemeTemplate (Interface)
| +-- StaticThemeTemplate
| +-- WeblogTemplate
+-- StaticTemplate (like the feed templates)
Resource (Interface)
+-- ThemeResource (Interface)
+-- StaticThemeResource
+-- WeblogResource
weblog.getTheme().getDefaultTemplate();
weblog.getTheme().getTemplateByName("foo");
weblog.getTheme().getResource("path/to/resource.img");
anyways, before this gets too long. does anyone object to doing this?
any reasons why we shouldn't do this? or ways we could do it better?
No objection here. Looks like a great improvement over what we have now.
Thinking about this for 4.0?
- Dave
