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
>
