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
