roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Gilliland <>
Subject Re: refactoring object model for themes
Date Thu, 05 Apr 2007 16:56:16 GMT

James M Snell wrote:
> I haven't been able to follow the discussion to this point.. but just a
> quick question: why are you deleting

WeblogResource is actually just being changed into ThemeResource, which 
represents a static resource file which is part of a Theme.  There will 
then be 2 implementations of ThemeResource ... 1 which represents a user 
uploaded file managed by the FileManager and the other being a file that 
is part of a shared theme.

The benefit here being that now whenever you are looking for a resource 
from a weblog's theme you don't have to keep duplicating the code which 
does ... if weblog uses shared theme, look there first, then look in 
FileManager ... instead, that logic is part of the Theme, so you just 
get to call Theme.getResource(path) and know that you are getting the 
resource back from wherever it may need to come from.

-- Allen

> - James
> Allen Gilliland wrote:
>> Here's the list of relevant files that I am planning to check in ...
>> M      src/org/apache/roller/pojos/
>> M      src/org/apache/roller/pojos/
>> D      src/org/apache/roller/pojos/
>> M      src/org/apache/roller/pojos/
>> A      src/org/apache/roller/pojos/
>> A      src/org/apache/roller/pojos/
>> A      src/org/apache/roller/pojos/
>> M      src/org/apache/roller/pojos/
>> M      src/org/apache/roller/pojos/
>> A      src/org/apache/roller/pojos/
>> M      src/org/apache/roller/pojos/
>> A     
>> src/org/apache/roller/business/themes/
>> A      src/org/apache/roller/business/themes/
>> A      src/org/apache/roller/business/themes/
>> A      src/org/apache/roller/business/themes/
>> A      src/org/apache/roller/business/themes/
>> M      src/org/apache/roller/business/themes/
>> A      src/org/apache/roller/business/themes/
>> Unless there are further questions or concerns I'd like to commit this
>> today.
>> -- Allen
>> Allen Gilliland wrote:
>>> 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"
>>>> <>
>>>> To: <>
>>>> Sent: Tuesday, April 03, 2007 2:19 PM
>>>> Subject: Re: refactoring object model for themes
>>>>> Dave wrote:
>>>>>> On 4/3/07, Allen Gilliland <> wrote:
>>>>>>> after spending a reasonable amount of time working on my various
>>>>>>> proposals which are all related to weblog design and customization
>>>>>>> have found that our object model for themes is not as well
>>>>>>> constructed
>>>>>>> as i think it should be.  the relationship between static themes
>>>>>>> custom weblog themes is kind of duct taped together right now
>>>>>>> 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
>>>>>>> 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
>>>>>> 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
>>>>>>> used to access all information
>>>>>>> about how a weblog design is defined.  So instead of having the
>>>>>>> object just represent a static theme, like it does now, I'd like
>>>>>>> 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
>>>>>>> using
>>>>>>> the Theme object.  A Theme would contain all resources relevant
>>>>>>> weblog design, which currently means templates & files.
>>>>>> Sounds good and I agree themes should be encapsulated as objects
>>>>>> 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
>>>>>> 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

View raw message