Maybe if you want listeners then only the session listen to those? And pages/components when they render pull the changes out of the session?
On 25/01/2009, Frank van Lankvelt <[email protected]> wrote: > But how is a view to know if its model (object) has changed in the pull > model? One way that I see this working is if views extract all state > that they need to do the rendering into a separate object. This object > is then recalculated from the model that is used by the view on each > request. Is this what you're suggesting? > > Of course one should not go about (de)serializing listeners carelessly. > I was a bit simplistic in describing what I want there, sorry 'bout > that. What I'm doing at the moment (with the listener leak) is that the > listeners that actually get registered with the object are stored in the > session. When they're called (asynchronously), they store events in a > queue. Then, when a request comes in, this queue is emptied by the page > that is being rendered; the events are processed by the in-page > listeners. This mechanism does depend on the use of sticky sessions, as > it has to be possible for an external service to invoke the (session) > listeners. > > The problem is now how to manage the listeners in the session. They > only need to be present for the "current" pages in pagemaps, i.e. those > pages that are shown and that will generate a request every now and then > using an ajax-timer. Other pages in the pagemap will be redrawn > completely when they need to respond to a request, so there is no need > for observation for them. > > Just realised that I can detect pagemap eviction by simply enumerating > the pagemaps when the session is detached. > > It seems to me that for wicket to support comet/bayeux, there will have > to be a solution for the kind of problems I'm running into here. I > don't think pushing the problem to the application developer (as I think > you are suggesting) is acceptable in the long run. > > Cheers, Frank > > >> From: Johan Compagner [mailto:[email protected]] >> Sent: 24 January 2009 19:58 >> >> I think having references to or from pages is a bad idea in >> wicket. We serialize pages so if pages would have listeners >> then the are also serialized. If others reference pages then >> after serialization/deserialization they point to the wrong instance. >> >> Way better is pure pull support. Components know where thet >> get its data from and they pull it on render and/or on a >> visitor that checks all components if they are changed. (and >> if changes add them to ajax request target) >> >> On 24/01/2009, [email protected] >> <[email protected]> wrote: >> > Use weakreferences to hold onto pages instead. >> > >> > -igor >> > >> > On 1/24/09, Frank van Lankvelt <[email protected]> wrote: >> >> I'm trying to get a page to observe a business object that >> can send >> >> events. The changes don't warrant a full page refresh, so >> I want to >> >> update only those parts of the page that have changed as a >> result of >> >> the events. >> >> >> >> I've seen wicketstuff-push, where a similar kind of observation is >> >> present in the Application. From what I could see, the >> chat example >> >> has the drawback that there is no *unregistering* of >> listeners when >> >> pages are disposed of, so there is a memory leak. (all >> pages will be >> >> kept in memory, being referenced directly by the service in the >> >> application) >> >> >> >> There doesn't seem to be any support for cleaning up >> pages, e.g. in >> >> the form of listeners that an application could register with the >> >> session store. An alternative seems to be to implement my own >> >> PageMap, but I'm reluctant to do that as there will be a lot of >> >> copy/paste involved and the existing PageMap >> implementations rely on >> >> the fact that they're in the same package as Session. A different >> >> alternative is to store all the listeners in a registry and use a >> >> separate thread to remove any listeners that are associated with >> >> pages that are no longer stored. Is there a better way? >> >> >> >> Thanks, Frank >> >> >> >> >> >> [email protected] www.onehippo.com >> >> Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam >> >> +31(0)20-5224466 >> >> San Francisco Hippo USA Inc. 101 H Street, suite Q Petaluma CA >> >> 94952-5100 +1-877-41-HIPPO >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > [email protected] www.onehippo.com > Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam > +31(0)20-5224466 > San Francisco Hippo USA Inc. 101 H Street, suite Q Petaluma CA > 94952-5100 +1-877-41-HIPPO > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
