Dave Johnson wrote:
On 6/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
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?
I don't think we can anticipate all of the things that a page model
author will need to access within a model and using a request here
stikes a good balance. Authors have access to the request and at the
same time we can provide access to request related things like the
parsed WeblogPageRequest object via request attibutes.
I agree, we can't anticipate everything that a page model would need,
but to me that is more of a reason to give it mode data than less data.
I definitely think that the original request will still go in the Map
of data passed into each page model, but using the Map instead of just
the request has a couple benefits in my mind ...
1. It's extensible. If at any time in the future we decide that each
page model should have something else at init time then it's trivial to
add it. Using just the request means we would have to refactor the
interface and all implementors to fit the need.
2. Custom implementations have more options. What if someone wants to
create their own servlet to add some functionality that we don't provide
and they create a custom page model for it? What if they want that page
model to be initialized with more data. Using a Map makes that easy
because the code that constructs the page model can pass in any data
they want.
3. It's more efficient. In many cases a servlet or other code will
already have done some parsing/validation on the request before the page
model is constructed. Why force that work to be duplicated? By letting
additional objects be passed into the init method we can reduce
redundant work like parsing the request, looking up pojos like the
Website object, etc.
So I think I am still a fan of using a Map instead of just the servlet
request for page model init. I don't think there is anything to lose by
doing it. We could alternatively have the init method be init(request,
Map data), so the page model is guaranteed to get the request and the
Map is purely optional extra data.
-- Allen
I do think the init method should throw an exception.
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.
Yes and that's essentially how the page model works now. It behaves
differerently based on what is in the request, so it does different
things if a specific day or month is specified.
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.
Yep. That's how they worked in 2.0 and they should continue to work.
- Dave
