Dave,
I wanted to go back to the beginning of this discussion and sidetrack on
a discussion about how the PageModel interface is defined and how the
page models are instantiated and used.
Right now the PageModel interface has this method for init ...
public void init(HttpServletRequest request);
... and I'm wondering if it would be better to make that init method
even more generic. I think that each page model implementation will
probably want to get a different set of initial data to make use of in
the model. For example, I can imagine that the WeblogPageModel may want
to use a parsed WeblogPageRequest, or a WebsiteData and WeblogEntryData
objects. So, I think there is definitely some potential uses for
initializing a page model with more than just the request object.
I am thinking that we could modify that init() method to this ...
public void init(Map data) throws ModelInitializationException;
... this way whatever piece of code is initializing that page model can
pass in a set of data that may be useful to the page model. We also
allow the page model to throw an exception during init if somehow the
page model doesn't receive all the data it needs or something else bad
happens during init.
think that makes sense?
The other smaller thing that I wanted to touch on is the idea that page
models do not need to be so generic that they don't behave differently
given different input. I think that some page models will certainly
want to behave a little differently based on the input they are given
during initialization. A good example of this would be the
WeblogPageModel.
I think it could be very useful if this model had a method like
getEntries() which simply returned the list of entries represented by
the request the model was constructed for. So if the request was for
the weblog homepage then it returns the most recent XX entries as
defined by the weblog settings. If the request is for a permalink then
it returns only a single entry. If the request is constrained by date,
category, etc, then it returns only the entries that are appropriate.
The benefit of an approach like this is that it takes the logic of what
entries to query for out of the macros and puts it into the model. This
is good because it keeps logic out of the "View" which is supposed to
only deal with display stuff.
Another example might be methods like getNextPageLink() and
getPrevPageLink() which may return links to the next/prev month in one
condition, but return links to next/prev entry in another situation.
The logic would be built into the method so that the view doesn't need
to worry about whether it's looking for the next entry, next month, next
entry in category, etc. All it needs is to ask for the next/prev links
and it gets back the right thing.
Anyways, you may already have been planning on doing that, but I wanted
to throw it out there anyways.
-- Allen
Dave Johnson wrote:
I've already started implementation of the new Atlas frontpage proposal:
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_Atlas
And today I posted the first draft of a new Atlas Page Macro/Models
proposal:
http://rollerweblogger.org/wiki/Wiki.jsp?page=ProposalAtlasMacroModels
The new Atlas macro/models proposal is pretty significant. I'm
proposing that we replace the old page models and macros that are used
in all existing Roller themes with an entirely new set of models and
macros. It's important that we get this right -- we don't want to have
to do this again.
The old system will still be available, but it will be possible to
either 1) leave it in place, 2) leave it in place but not allow new
blogs to use it or 3) to turn if off entirely.
Please review and offer feedback.
- Dave
