Craig McClanahan wrote:
On 6/10/05, Werner Punz <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote:
Solving these sorts of problems is exactly what the Shale framework
(part of the Struts project) is designed to address. Current starting
point for info is on the wiki (i'm working up the docs for the
website).
http://wiki.apache.org/struts/StrutsShale
You'll be interested particularly in the ViewController interface, and
the fact that it gives you event callbacks at the beginning and end of
a view (init and destroy) and well as other events dependent upon
whether you are processing a form submit or not (preprocess and
prerender). Shale presumes that JSF exists, and leverages its front
controller framework rather than treating JSF just as a mechanism for
constructing the view.
Craig
Thanks for the fast answer, you basically already implemented the
approach I was thinking of, great... you saved me lots of work.
A question however, could this stuff be moved into some kind of
extended datamodel, so that the datamodel implementors do not have
to deal with event callbacks into the view controller?
I was actually thinking that things would work the other way around
... the event callbacks are view lifecycle things that would trigger
calls in to the datamodel to acquire and release resources. For
example, if you needed a Hibernate session to grab some data needed to
render the current page, you might put the acquisition code in
prerender() and release it in destroy() ... without the session
needing to be explicitly aware that it is being used this way. A
datamodel implementation around a Hibernate session ought to be able
to work the same way -- part of the contract of using it would be to
call lifecycle methods on the datamodel itself at appropriate times.
Well, I think, I was to unprecise, that exactly was my point of
being probably the best way...
:-)
Thanks again for clarification.
