I haven't been able to follow the discussion to this point.. but just a quick question: why are you deleting WeblogResource.java?
- James Allen Gilliland wrote: > Here's the list of relevant files that I am planning to check in ... > > M src/org/apache/roller/pojos/Theme.java > M src/org/apache/roller/pojos/WeblogTemplate.java > D src/org/apache/roller/pojos/WeblogResource.java > M src/org/apache/roller/pojos/ThemeTemplate.java > A src/org/apache/roller/pojos/WeblogTheme.java > A src/org/apache/roller/pojos/StaticThemeTemplate.java > A src/org/apache/roller/pojos/ThemeResource.java > M src/org/apache/roller/pojos/Template.java > M src/org/apache/roller/pojos/StaticTemplate.java > A src/org/apache/roller/pojos/Resource.java > M src/org/apache/roller/pojos/WebsiteData.java > A > src/org/apache/roller/business/themes/SharedThemeResourceFromDir.java > A src/org/apache/roller/business/themes/SharedThemeTemplate.java > A src/org/apache/roller/business/themes/WeblogSharedTheme.java > A src/org/apache/roller/business/themes/SharedTheme.java > A src/org/apache/roller/business/themes/SharedThemeFromDir.java > M src/org/apache/roller/business/themes/ThemeManager.java > A src/org/apache/roller/business/themes/WeblogCustomTheme.java > > 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" >>> <[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 >>>> >>> >
