comments inline ...
Dave Johnson wrote:
As I do the work to add Atlas page models to Roller, I'd also like to
refactor
the existing page model and context loading process to address a couple of
problems:
- Context loading process should not do unncessary work
- Context loading process and page models should not depend on Velocity
Definitely agree with these 2 objectives.
To accomplish this, I'm proposing that we:
1) establish a simple TemplateContext interface so page models can deal
with the Velocity Context in a generic way. Something simple like this:
interface TemplateContext
put(String s, Object o)
Object get(String s)
I'm not sure that we want the Models to have the ability to talk the
VelocityContext, but if we do then I would prefer we just use a Map. I
can't see any reason to make our own interface/implementation when it
does the same thing as a Map.
2) we eliminate the ContextLoader class and make page models responsible
for loading the template context with the various globals that are
associated
with the page model.
I would actually prefer that Models don't have any knowledge of the
VelocityContext or a generic equivalent. I think the Models should be
totally self contained, so they shouldn't need to know how/where they
are being used.
Unfortunately this means we basically would need to leave the existing
ContextLoading stuff as is, but consider it deprecated. Then moving
forward we redo our velocity themes/templates to use the new model objects.
3) we create three different page models for our three different rendering
situations: weblog display, weblog entry/comments display and feed display.
First, all page models implement this interface because they're pluggable:
interface PageModel
getModelName()
init(request, response, TemplateContext)
The WeblogPageModel becomes the new home for most of the code that was in
the old ContextLoader class, except for entry/comment and feed stuff.
class WeblogPageModel implements PageModel
Same as old PageModel class
Init method loads TemplateContext (as ContextLoader once did)
The WeblogEntryPageModel extends WeblogPageModel because
entry/comments pages need the old PageModel methods. It's init method
calls super.init() and also loads comment specific values.
WeblogEntryPageModel extends WeblogPageModel
Init method loads TemplateContext with values needed for entry/comments
The FeedPageModel extends WeblogPageModel, because our feed templates
(atom.vm
and rss.vm) depend on the old PageModel. The ContextLoader code that loaded
RSS values goes here.
FeedPageModel extends WeblogPageModel
Init method loads TemplateContext with values needed for feeds
This is a fairly different approach than what I was thinking about. In
this approach you aren't really using Models just to provide rendering
functionality, instead they are used in large part for providing context
loading functionality. I would prefer that we keep those 2 things
separate actually.
An example is the way we use Models in the admin/authoring UI struts
pages. The struts actions load up the model (jsp scopes like request,
page, session) with any objects or Models that are to be used at
rendering time. However the Models are not allowed to write their own
stuff to the jsp scopes. I would prefer we follow this approach.
What I am proposing is that instead of setting up the VelocityContext
like we have in the past, where it's littered with dozens and dozens of
variables everywhere. Instead we just load it with Models moving
forward and all rendering functionality is used via the models.
4) change the PageServlet and FlavorServlet classes to load the appropriate
page models.
class PageServlet
if no weblog entry is specified
Create page model specified by "weblogpagemodel.classname"
put it into context
else
Create page model specified by "weblogentrypagemodel.classname"
put it into context
for each additional page model specified by current weblog
Create page model
put it into context
class FlavorServlet
Create page model specified by "feedpagemodel.classname"
put it into context
I still agree with this sentiment that the Servlets should load only the
models which are needed/allowed to render the content, but I am not on
board with all the various Models that you listed.
-- Allen
Thoughts, comments, objections?
- Dave
