Umm, I see. But shouldn't it be interesting for this specific problem to just have some kind of callback mechanism in the DataModel, so you could 'do something' everytime a row is rendered?
I mean, you could get a reference to the current object in order to reattach it to the new session... What do you think? Maybe it's as simpler as reimplementing the actual DataModel with callback mechanisms... 2005/6/20, Werner Punz <[EMAIL PROTECTED]>: > Enrique Medina wrote: > > Hi Werner, > > > > I see. Regarding to your comments about Shale, do you mean that Shale > > will allow me to have a reference to every object that is prsented in > > the DataModel, so for example I will be able to reattach it to the new > > Hibernate session using Hibernate.lock(object, LockMode.NONE)? > > > No... from what I could gather from Clanahans comments you will > finally get clear demarkation boundaries on when you can aquire > resources before rendering and when you can drop it after the rendering > is done. > Shale finally has a mechanism which you can bend towards following states. > > 1) I am before rendering aquire the resources you need > 2) Rendering is done release the resources. > > That means you finally know when the rendering starts and can aquire the > session, and then finally you also know when the rendering is done and > you can drop the session. > In your case this helps for the data table that you can open the session > at the beginning of the rendering stage, you can use lazy loading to > load the data just needed for the data table, and once the rendering is > done you can drop the session. > > The current state of affairs is, you have to preload the data and serve > it row by row (object by object) and thus you cannot keep the session, > open during rendering, or you have to keep the session open until a > stage you cannot control anymore. Therefore you automatically if you > follow the first approach, you run into lazy loading problems, you have > to resolve manually. > > Here is the original comment of Clanahan on which mechanism you can use > to resolve the whole issue: > > ----- > > 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. > >
