As a side note, we could zip the request for temporary storage in the
session, and unzip it when served (preferable hot). This would exchange
some processing power for space...
Martijn
Eelco Hillenius wrote:
> Note for list: this is an idea we discussed at Topicus (means Martijn
> - came up with the idea -, Johan and I) today. Basically, all
> processing is now done in one pass, but when redirect is true, the
> response is buffered instead of send to the output stream, and the
> redirect is used to get that buffered response. Only potential
> problems I see with it, is that it consumes more memory potentially,
> though as all processing is done in one pass, it might save a bunch of
> temporary objects that were used otherwise.
>
> Could Johan check his code in (as a branch?), and could you - Chris,
> Juergen, Jonathan (if you're not shooting a movie) - take a look at
> it? It seems pretty important to me (read 1.0) to have a solid answer
> to some of the problems with the current redirect pattern.
>
> Eelco
>
> 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).setAttribute("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
