This would all be so much easier with just one tiny change to the HTTP protocol. All you would need to do is be able to (optionally) set a response header with a url that the browser should change the address bar to and which the browser should then use to refresh the page (instead of the original url used to retrieve the page). Simple, all problems solved. Anyone want to implement it? ;)
>
>
> The Hibernate session can't be replicated. It will give an error when
> you try to. And it surely is a VERY bad thing to do so... I
> repeat: it
> is a very bad thing to store your hibernate session in the
> http session.
>
> The problems we try to tackle here are:
> - performance: it is not a good thing for performance to perform the
> action in a serverside action, and the render in another (possibly on
> another server). This basically means that you have to rebuild the
> detached state. When things get big, you don't want that.
> - keeping the (hibernate) session alive for rendering makes
> development
> a lot easier. You can pass objects around. Pure POJO development is
> around the corner.
> - redirect after post: IMO it is not perse an antipattern.
> It is still
> sound to use this, but we don't want to incur the penalty of
> recreating
> the state when everything is already there just before the redirect.
>
> As far as I know, in order to rebuild the page from the stored page
> state in the session, you still need the model data. Which means
> re-attaching (reloading all models!) and a hence a penalty.
>
> I want us to consider supplying different strategies for this request
> processing:
> - the current strategy with redirect and rendering after the redirect
> - the proposed strategy with redirect and rendering before
> the redirect
> - a new strategy with plain old POST without redirect
> - anything we can think of
>
> Martijn
>
>
> Jonathan Locke wrote:
>
> >
> > right right... so the Page that's being rendered on the redirect is
> > already in the session and it's already being replicated.
> > which brings me back to my earlier thought... if the page you're
> > redirecting to is already replicated and in the session, then the
> > request could occur on server A and the response could come from
> > server B simply because the Page was constructed (and
> therefore is in
> > the session). so if this is the case, i've flipped my opinion back
> > around... why can't the hibernate session just be opened on
> begin(A)
> > and be closed on end(B) ??
> >
> > sorry i've been free associating tonight i really only have like 15
> > minutes to respond to all this tonight... i'm still a
> little lost on
> > this, but i'm unsure about the solution still. can someone follow
> > through my thoughts and questions and set me straight? thanks!
> >
> > best,
> >
> > jon
> >
> > Jonathan Locke wrote:
> >
> >>
> >> okay, so if we do decide to do it this way, a couple questions...
> >>
> >> - why a map? isn't there only one redirect at a time for
> a session?
> >> couldn't this be a single attribute
> >>
> >> - shouldn't you remove the attribute at the end of the redirect?
> >>
> >> - why use this low-level way of getting the session attribute?
> >> shouldn't you just say
> getSession().getAttribute("wicket-redirect") ?
> >>
> >> Johan Compagner wrote:
> >>
> >>> We always do clientside redirects. So developer don't always take
> >>> this into account.
> >>> Like setResponsePage(new Page(myHibernateObject))
> >>> then myHibernateObject uses a wrong HibernateSession.
> >>>
> >>> ClientSide redirect do fix a number of problems so we like to keep
> >>> this.
> >>>
> >>> Now i made a hybrid solution.
> >>> We do use a clientside redirect put the responsepage is
> rendered as
> >>> it was a serverside redirect...
> >>>
> >>> Changed 2 classes/methods:
> >>>
> >>> WebRequestCycle.redirectTo(final Page page)
> >>> {
> >>> String redirectUrl = page.urlFor(page,
> IRedirectListener.class);
> >>> // create the redirect response.
> >>> Response previous = getResponse();
> >>> RedirectResponse rr = new RedirectResponse(redirectUrl);
> >>> setResponse(rr);
> >>> page.request();
> >>> setResponse(previous);
> >>> Map map =
> >>>
> (Map)getWebRequest().getHttpServletRequest().getSession(true).
> getAttribute("wicket-redirect");
> >>>
> >>> if(map == null)
> >>> {
> >>> map = new HashMap(3);
> >>>
> >>>
> getWebRequest().getHttpServletRequest().getSession(true).setAt
> tribute("wicket-redirect",map);
> >>>
> >>> }
> >>> map.put(redirectUrl,rr);
> >>> // Redirect to the url for the page
> >>> response.redirect(redirectUrl);
> >>> }
> >>>
> >>> So when we redirect the page is first rendered
> (page.request()) in
> >>> a buffered response object.
> >>> this object is stored in the httpsession.
> >>> Then the redirect is done.
> >>>
> >>> in:
> >>>
> >>> WicketServlet.doGet(final HttpServletRequest servletRequest,
> >>> final HttpServletResponse servletResponse) throws
> >>> ServletException, IOException
> >>> {
> >>> // try to see if this is a redirect that is
> already stored in
> >>> the wicket-redirect map of its session.
> >>> Map redirectMap =
> >>>
> (Map)servletRequest.getSession(true).getAttribute("wicket-redirect");
> >>> if(redirectMap != null)
> >>> {
> >>> RedirectResponse rr =
> >>>
> (RedirectResponse)redirectMap.remove(servletRequest.getRequestURI()
> >>> + "?" + servletRequest.getQueryString());
> >>> if(rr != null)
> >>> {
> >>> PrintWriter pw = servletResponse.getWriter();
> >>>
> servletResponse.setContentLength(rr.getContentLength());
> >>>
> servletResponse.setContentType(rr.getContentType());
> >>> pw.write(rr.toString());
> >>> pw.close();
> >>> return;
> >>> }
> >>> }
> >>> // Get session for request
> >>> final WebSession session =
> >>> webApplication.getSession(servletRequest);
> >>>
> >>> I first test if there is a redirect response item in the redirect
> >>> map. If this is the case then that redirect object is
> removed from
> >>> the map and the redirect is written to the directly
> written to the
> >>> response.
> >>>
> >>> the drawback:
> >>> There is a complete page in mem of the server for a very
> short time.
> >>>
> >>> plus:
> >>> the redirect is very very fast. And doesn't take almost no memory,
> >>> no hibernate session need to be created nothing needs to
> be loaded.
> >>>
> >>>
> >>> Any objections for this approach?
> >>> We could make it optional or something
> >>>
> >>> johan
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> SF.Net email is sponsored by: Tell us your software development
> >>> plans! Take this survey and enter to win a one-year sub to
> >>> SourceForge.net Plus IDC's 2005 look-ahead and a copy of
> this survey
> >>> Click here to start!
> >>> http://www.idcswdc.com/cgi-bin/survey?id=105hix
> >>> _______________________________________________
> >>> Wicket-develop mailing list
> >>> [email protected]
> >>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >>>
> >>
> >>
> >> -------------------------------------------------------
> >> SF.Net email is sponsored by: Tell us your software development
> >> plans! Take this survey and enter to win a one-year sub to
> >> SourceForge.net Plus IDC's 2005 look-ahead and a copy of
> this survey
> >> Click here to start!
> http://www.idcswdc.com/cgi-bin/survey?id=> 105hix
> >>
> _______________________________________________
> >>
> Wicket-develop mailing list [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >>
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Tell us your software
> development plans!
> > Take this survey and enter to win a one-year sub to SourceForge.net
> > Plus IDC's 2005 look-ahead and a copy of this survey Click here to
> > start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
> > _______________________________________________
> > Wicket-develop mailing list [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software
> development plans! Take this survey and enter to win a
> one-year sub to SourceForge.net Plus IDC's 2005 look-ahead
> and a copy of this survey Click here to start!
> http://www.idcswdc.com/cgi-bin/survey?id=> 105hix
>
> _______________________________________________
>
> Wicket-develop mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
