this should go to separate conversation I created stateless (no stateful components) page if user is authorized i put his id to session so I can load it on each page creation (since it is stateless and not versioned it will be created on each request)
pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski....@gmail.com ______________________ On 9 January 2012 12:39, 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
