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:jcompag...@gmail.com] > 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, igor.vaynb...@gmail.com > <igor.vaynb...@gmail.com> wrote: > > Use weakreferences to hold onto pages instead. > > > > -igor > > > > On 1/24/09, Frank van Lankvelt <f.vanlankv...@onehippo.com> 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 > >> > >> > >> f.vanlankv...@onehippo.com 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: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > f.vanlankv...@onehippo.com 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
