What about using the @StatelessComponent (moving it from devutils into wicket) as an indicator, that pages are intended to be stateless (_must_ be stateless)? Or introduce a new annotation @StatelessPage?
When a page that is intented to be stateless turns to be stateful, it's always an issue (small or big one). Probably there are cases where pages *should* be stateless and it doesn't really matter if they get stateful, but there are also other cases, where pages *must* be stateless, e.g. due to high load. The @Stateless annotation would target the latter cases, where pages *must* be stateless. And in this case, the pageIdCounter should also not be modified. What do you think? Cheers, Martin On Sun, 2010-03-14 at 00:18 +0100, Martin Grotzke wrote: > There are cases where pages are intended to be stateless (and might get > annotated with @StatelessComponent). At least for these pages the page > id should not be incremented, even if the session already has been > bound. > > Cheers, > Martin > > > On Sat, 2010-03-13 at 22:58 +0100, Matej Knopp wrote: > > I'm not sure about all this. > > > > If the session has not been bound the page id will always be 0. If the > > session has been bound, I don't think we shouldn't increment page Id. > > Stateless page can became stateful any time, not incrementing the id > > can have sideeffects. > > > > -Matej > > > > On Sat, Mar 13, 2010 at 10:55 PM, Martin Grotzke > > <martin.grot...@javakaffee.de> wrote: > > > Hi, > > > > > > just submitted this as > > > https://issues.apache.org/jira/browse/WICKET-2782 > > > > > > I tried incrementing the pageId when the page's numericId is first > > > accessed, but soon realized, that this does happen rather often (also > > > e.g. to construct bookmarkable page links) ;-) Seems to be not as easy > > > as I thought. Still, it would be really cool if this could be > > > implemented! > > > > > > Cheers, > > > Martin > > > > > > > > > On Wed, 2010-03-10 at 08:49 -0800, Igor Vaynberg wrote: > > >> i think we can do this in 1.5 > > >> > > >> i would rather not mess with 1.4 because i think there is a lot of > > >> code there that depends on the fact that the id is available right > > >> away. > > >> > > >> please create a jira issue for this > > >> > > >> -igor > > >> > > >> On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke > > >> <martin.grot...@javakaffee.de> wrote: > > >> > Hi, > > >> > > > >> > the Page.init(PageMap) invokes setNextAvailableId(), which invokes > > >> > getSession().nextPageId() if isPageIdUniquePerSession is set. > > >> > > > >> > getSession().nextPageId() modifies the Session.pageIdCounter. > > >> > > > >> > When I have a session and afterwards access a stateless page, the > > >> > Session.pageIdCounter is the only data that is changed in the session > > >> > AFAICS, everything else is the same as in the request before. > > >> > > > >> > Is it possible _not_ to modify the Session.pageIdCounter if the page is > > >> > really stateless (or just don't invoke Page.setNextAvailableId())? > > >> > > > >> > I'm interested in this, as I'm just implementing a feature for the > > >> > memcached-session-manager ([1], memcached based session replication), > > >> > which checks if session data has changed and replicates sessions only > > >> > if > > >> > this is provided. If session data did not change, the replication is > > >> > omitted. Therefore, if the Session.pageIdCounter would be left > > >> > unchanged > > >> > for stateless pages, this would allow to make use of this feature in > > >> > wicket apps. > > >> > > > >> > Thanx && cheers, > > >> > Martin > > >> > > > >> > > > >> > [1] http://code.google.com/p/memcached-session-manager/ > > >> > > > >> > > > >> > > > >> > > >> --------------------------------------------------------------------- > > >> 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 > > >
signature.asc
Description: This is a digitally signed message part
