Well, the next thing indeed is that session constructor. What do we need that for anyway?
We obviously have to make a choice here. Either requests run in the scope of a session, in which case we can't/ shouldn't defer creating an httpsession when that's the session store, or they don't have to run in the scope of the session, in which case we should loose the constructor argument and parameter (which is just an optimization). Eelco On 4/11/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > fine by me but RequestCycle constructor needs a session. So are we also > removing that? > And only make a session when it is asked for ? > > Because then ISessionStore needs some update (again) because then we need a > boolean in most > calls (for example getSessionId() will make the session now but it should be > optional then) > > johan > > > > On 4/11/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote: > > > We can investigate it further, but I'd like to state that Wicket never > worked without having any session, as a session object is needed > (thought theoretically not bound to any httpsession object) for > creating a request cycle. > > The first thing we thus need to do is to move request cycle > construction from session to application. Unfortunately, that will > mean an API break. It's an easy enough fix, and I don't expect custom > request cycles to be used that much, but still. > > So, here we go: are you ok with moving request cycle construction from > session to application: > > [ ] yes > [ ] no > > Vote is open for all members of this list. > > Eelco > > > > > On 4/11/06, Johan Compagner <[EMAIL PROTECTED] > wrote: > > that is a bit let go in the last refactor eelco and i made to > ISessionStore > > and the implementations. > > > > It is very hard to do. For example the PageMap always finds itself dirty > and > > wants to store itself > > if you make one page (stateless or not) > > > > We could maybe optimize this by calling Page.init() not in the constructor > > but in getId() or getPageMap()? > > But that is all very tricky i think. > > > > johan > > > > > > > > On 4/11/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > > > i think the point was not to create a session at all unless a > > non-stateless page is invoked. > > > > > > > > > -Igor > > > > > > > > > > > > > > > On 4/11/06, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > > > > > > See my other post. > > > > Sessions are created now everytime to store the session object and the > > first default pagemap. > > > > After that you only need to make sure that you only use bookmarkable > > links and don't use a > > > > wicket form component.. (and any ajax behaviours/component ofcourse) > > > > Then the pages won't go into the session. > > > > > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > On 4/11/06, SourceForge.net <[EMAIL PROTECTED] > wrote: > > > > > Feature Requests item #1468169, was opened at 2006-04-11 03:45 > > > > > Message generated for change (Tracker Item Submitted) made by Item > > Submitter > > > > > You can respond by visiting: > > > > > > > > https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1468169&group_id=119783 > > > > > > > > > > Please note that this message will contain a full copy of the > comment > > thread, > > > > > including the initial issue submission, for this request, > > > > > not just the latest update. > > > > > Category: None > > > > > Group: None > > > > > Status: Open > > > > > Priority: 5 > > > > > Submitted By: Gili Tzabari (cowwoc) > > > > > Assigned to: Nobody/Anonymous (nobody) > > > > > Summary: Document requirements for "stateless" page > > > > > > > > > > Initial Comment: > > > > > It seems like most people, myself included, aren't 100% > > > > > sure what requirements a "stateless" page has. How do > > > > > we ensure a Page does not generate a new Session when > > > > > it is hit? Please document this somewhere. > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > You can respond by visiting: > > > > > > > > https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1468169&group_id=119783 > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email is sponsored by xPML, a groundbreaking scripting > > language > > > > > that extends applications into web and mobile media. Attend the live > > webcast > > > > > and join the prime developer group breaking into this new coding > > territory! > > > > > > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > > > > > _______________________________________________ > > > > > Wicket-develop mailing list > > > > > [email protected] > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
