Anil Gangolli wrote:
I like the idea of cleanup in this area, but I have lots of questions.
questions are good =)
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?
The distinction between "Static" and "Weblog" is because we have
multiple contexts in which we use themes, templates, and resources and
the behavior changes a bit depending on the context. The context
these items are used in is all related to rendering and currently we
only consider rendering weblog templates, however that isn't the right
solution, especially with the new widgets stuff coming in and with the
potential for rendering other kinds of pluggable components.
So the interfaces for Theme, Template, and Resource are meant to be
the most generic forms of those things. Then they are subclassed to
provide more targeted interfaces for specific use cases, such as for
use by a weblog or for use by a widget.
I think I am going to change the naming from "Static" to "Shared"
because I think that will make it a bit easier to understand.
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?
yes. as I got a little further in the code I realized I didn't fully
detail the necessary object hierarchy for themes. it will be ...
Theme (IF)
|
+-- SharedTheme (impl)
|
+-- WeblogTheme (IF)
|
+-- WeblogSharedTheme (impl)
|
+-- WeblogCustomTheme (impl)
so the Theme interface simply defines a way to access the elements
which compose a theme, and the SharedTheme implements that interface
and provides a way to get at those resources off a filesystem right
now. the WeblogTheme represents a theme as attached to a specific
weblog and provides an implementation which is backed by a shared
theme and one which is not. Neither are modifiable right now because
there is no need, we don't persist the data, but if we decided to do
that then we could add that in.
for the most part this is just an organizational improvement and not
much more. it allows us to build up the functionality regarding
themes in a more logical and extensible way because we now access all
weblog theme data through a proper interface so we can control the
underlying functionality by plugging in different implementations very
easily. For example, there are various ways you might implement a
SharedTheme, one might be our current approach via a folder on the
filesystem, a new approach might be via a jar archive on the
filesystem, a third approach might be in the database somehow, etc.
ultimately i think this bit of reorganization provides a more natural
way of accessing this data in the object model and better encapsulates
the logic.
hopefully that makes some more sense.
-- Allen
--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
