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. > Shale might be a good place to resolve this issue there. > Since you already have the base mechanisms in place. > > Thanks for your fast answer > Gotta do something while my application builds ... even on a fast machine it's many minutes :-). > Werner > >
