It would also be nice if there was an option to disable Theme caching and velocity macro caching in general - for those people who write Themes (some of our UI people absolutely hate working with Roller because of this).
The way it is now, the Themes are cached statically during startup, and when a theme developer decides to change it slightly, he / she would have to restart the servlet instance. The velocity macro's too are static as it's using the classpath resource loader. It would be nice if there was some of global profile in the roller-custom.properties that would disable all forms of caching being performed when under development. -----Original Message----- From: Anil Gangolli [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 8:20 AM To: [email protected] Subject: Re: refactoring object model for themes 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 >
