Hi, I see there is a big misunderstanding of what stateless/ful actually is. Having an http session or not is related only to the fact that stateful pages are stored there. Nothing more. You still can have an authenticated user (i.e. http session) and show stateless pages. All user info panels that you mentioned below doesn't require stateful page by itself.
A page is stateful if it has at least one stateful component or behavior. A stateful component/behavior (C/B)is one that keeps a state with it and that state is needed by the C/B in the next request(s). Such C/B may have a callback url - an url which uniquely identifies this C/B and this C/B can be requested. In the simple and most used case imagine a Link with its onClick() method. So if you keep your pages stateless (by avoiding components and behaviors which makes it stateful. See StatelessChecker in wicket-devutils.jar) you can still show user's account info. A common use case is with Ajax C/Bs. An Ajax call updates just a part of the page. By default Wicket provides stateful Ajax C/Bs, i.e. they update parts of the same page instance. Jolira's Ajax C/Bs are stateless - i.e. an Ajax call creates a completely new page, then updates the part(s) it needs, then delivers the markup for the updated components in the Ajax response and discards the newly created page. I guess we need to create a Wiki page that better explains what is the difference between stateless and stateful. On Mon, Jan 9, 2012 at 1:39 PM, Chris Colman <chr...@stepaheadsoftware.com> wrote: > The stateless/stateful issue, on the surface at least, seems to be trivially > easy because it's so black and white. Obviously in an ideal world most pages > should be made stateless but in all but trivial sites this is near > impossible. I'd like to suggest there is a fair amount of 'gray' - that > things aren't so 'black and white' in the real world. > > For example - the content on most of the pages on our sites are essentially > stateless - showing product details or FAQ pages or About Us pages until you > realize that *every* web app that has authentication (which one doesn't these > days?) shows the currently logged on user's username in an 'account details' > component in the top/right of each page with an option to change profile > settings and log out etc,. This has become much more than just a convention - > it's virtually a defacto standard. > > Once we add that very common account details component to the top of each > page the pages essentially become stateful so essentially a site with > predominantly stateless pages now has to be stateful. > > The main issue that I am trying to avoid by removing page versions is SEO > confusion whereby each time a search engine looks at a URL it sees a > different page version parameter in the URL. It's a similar problem to the > famous jsessionid parameter issue. > > Given that search engines never authenticate it prompts the question: is it > possible for a given page to have multiple personalities? i.e. stateless if > no authentication has taken place and stateful if authentication has taken > place. > > User's don't really care if there is an extra page version parameter in the > URL and this can be of great assistance in making the back button function > correctly - especially if their interactions have changed content on the > various pages (eg. showing contents of their shopping cart - hmmm, that's a > problem - probably always want to show the 'current' shopping cart contents > no matter how much they have gone 'back' otherwise things could get quite > confusing) > > Search engines, on the other hand, don't really want to see the extra page > version parameter. > > Setting up pages to have dual personalities would be a most excellent > solution methinks. Is this possible/easy/a good idea in Wicket? > > Is it something that is such a common requirement that it could be added to > the Wicket framework as a built in feature and save hours of work for both > experienced and newbie Wicketeers? > > If it were a switchable option built into the framework wicket would only > need to query the AuthenticatedWebSession.isSignedIn() to determine if each > page should be stateless or stateful. Or perhaps an IAuthenticator interface > needs to be supplied to allow it to work for developers who implement their > own authenticated session object. > > Just thinking aloud ... again ;) > > Regards, > > Chrisco > >>-----Original Message----- >>From: Martin Grigorov [mailto:mgrigo...@apache.org] >>Sent: Monday, 9 January 2012 8:37 PM >>To: users@wicket.apache.org >>Subject: Re: stateless, not versioned pages - session problem >> >>On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman >><chr...@stepaheadsoftware.com> wrote: >>>>On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman >>>><chr...@stepaheadsoftware.com> wrote: >>>>>>> Not sure if I have an answer to your question but recently I asked >>how >>>>to >>>>>>turn off page versioning and was told to do: >>>>>>> >>>>>>> getRequestCycleSettings(). >>>>>>> >>>> setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); >>>>>> >>>>>>Actually this just turns off the redirecting. The pages are still >>>>>>versioned. >>>>> >>>>> So would >>>>> >>>>> getPageSettings().setVersionPagesByDefault(false); >>>>> >>>>> have been a better/safer option for turning off page versioning? >>>> >>>>Yes. >>> >>> I tried setVesionPagesByDefault(false) on its own but the version >>parameters still appeared in the URL in the browser address bar. Should we >>use both of the above to make page versioning disappear so as to make >>Wicket 1.5 behave just like version 1.5? >> >>Make your page stateless to not have page ids in the URL (and the page >>wont be saved in the page stores too). >>Otherwise you'll need special version of >>org.apache.wicket.request.mapper.MountedMapper#mapHandler that doesn't >>org.apache.wicket.request.mapper.AbstractComponentMapper#encodePageComponen >>tInfo >>for IPageRequestHandler. >> >> >>> >>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>> >>>> >>>> >>>> >>>>-- >>>>Martin Grigorov >>>>jWeekend >>>>Training, Consulting, Development >>>>http://jWeekend.com >>>> >>>>--------------------------------------------------------------------- >>>>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 >>> >> >> >> >>-- >>Martin Grigorov >>jWeekend >>Training, Consulting, Development >>http://jWeekend.com >> >>--------------------------------------------------------------------- >>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 > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
