I like the idea of cleanup in this area, but I have lots of questions.
I'm not entirely following the distinction between "Static" and "Weblog" in
the type structure, and what causes the type differences to extend down into
templates and resources?
Can one construct a "WeblogTheme" starting from a "StaticTheme"? Once one
has done that, what's the difference. Is there a difference other than one
is read-only and one is modifiable?
--a.
----- Original Message -----
From: "Allen Gilliland" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, April 03, 2007 2:19 PM
Subject: Re: refactoring object model for themes
Dave wrote:
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?
yes, I am working on it right now actually. the main reason i thought of
it and need to do it now is because with the work i've done so far i've
had to do some work arounds basically because the stuff above isn't
already in place. with the widgets and panels stuff it becomes even more
important because if we leave things unchanged from how they are now then
adding widgets and panels will make things a bit more messy.
the amount of work here isn't all that much, it's really just changing a
few things which were classes into interfaces and then providing a couple
new implementations. i am expecting to have the bulk of it done in the
next day or so.
-- Allen
- Dave
