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 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
