A couple of things:

1. I think the removal of _sourcePage is ok for GET links.  But I  
think we should add a parameter to s:link/s:url that allows the  
inclusion of it.

2. I'm a little more concerned about the fields present stuff. That's  
used, not only as a part of wizards, but also to determine how to  
handle checkboxes and multi-selects since most (all?) browsers submit  
nothing in the request if these controls are unselected.  Turning off  
this when there is no session seems to degrade the functionality of  
Stripes and would be rather confusing to most users

3. I'm with Remi. Submit some patches for this stuff!  Ideally  
separately so we can apply them in pieces.. for examples the  
getSession().getServletContext() stuff could all be done immediately

-t


On Mar 28, 2007, at 7:22 AM, VANKEISBELCK Remi wrote:

> Yikes !
>
> Could you associate your updates to open issues in the JIRA (or create
> new ones) and send us some patches ? I'm particularly interested in
> your solution for the _sourcePage param, as it'd boost the development
> of the Clean URLs stuff... and I'd be happy to integrate your patch if
> everything is ok.
>
> Hence, the question : does everyone here agree on the fact that
> validation isn't necessary for <s:link> ? I do, as it's the dev.'s
> responsability to ensure that the links he/she generates are valid. In
> case of users hack ing the urls, a good old error page is sufficient
> IMHO, no need for supporting error messages etc. as far as I see...
>
> Others, do you agree on that ? Can we get rid of _sourcePage for  
> links ?
>
> Also, what about <s:url> ?
>
> Cheers
>
> Remi
>
>
> On 3/28/07, Sebastian Beigel <[EMAIL PROTECTED]> wrote:
>> Hi everybody,
>>
>> I have the requirement to use no http session for some pages in my
>> current (Stripes) web app. Unfortunately, Stripes is very  
>> aggressive WRT
>> the creation of a http session :)
>>
>> I had to do several changes to tame Stripes' session creation a  
>> little bit:
>>
>> First and foremost, replace all occurrences of
>>
>> request.getSession().getServletContext()
>>
>> with
>>
>> StripesFilter.getConfiguration().getServletContext()
>>
>> I hope the former is just "legacy" code that's not already  
>> refactored to
>> the latter version (which runs without side effects).
>>
>>
>> Next stop is the DispatcherServlet where Stripes creates a  
>> PageContext
>> for its EL-based validation. The 5th argument in
>> JspFactory#getPageContext() is called something like "needSession"  
>> and
>> is set to "true" which results in the creation of a http session  
>> if none
>> is present. I refactored from
>>
>> true
>>
>> to
>>
>> (abc.getRequest().getSession(false) != null)
>>
>> That way, getPageContext() "needs a session" only if there is one
>> already created.
>>
>>
>> Last thing to do is the handling of present fields in Stripes'  
>> form tag.
>> As "present fields" isn't absolutely necessary for every form, I made
>> its inclusion dependent on the existence of a http session. If  
>> there's
>> one created already, the "__fp" attribute is rendered in the  
>> content is
>> stored in the session. If no session is present, the "present
>> fields"-code it ommitted.
>>
>> BTW, as discussed several times on the lists, I refactored  
>> "sourcePage"
>> to be encrypted and stored in the session (like "present fields")  
>> as I
>> don't want to expose that much inner detail of my web app to the  
>> world
>> :) And I stripped it off completely from Stripes' link-tag urls as I
>> don't think it's appropriate to have it there (normally there's no
>> "right" source page to correct validation errors anyways if you  
>> follow a
>> "<s:link ...").
>>
>> I think it would be best to supply arguments to the link and the form
>> tag to control the usage of "present fields" and maybe "sourcePage".
>>
>>
>> Sebastian
>>
>>
>> --
>> Sebastian Beigel // Software Architekt
>> (F) Die Firma GmbH // Innovative Kommunikation
>> Schwalbacher Straße 74 // D-65183 Wiesbaden
>> T +49.6 11.2 38 50.24 // F +49.6 11.2 38 50.11
>> mailto:[EMAIL PROTECTED] // http://www.diefirma.de
>>
>> Amtsgericht Wiesbaden // HRB 1091
>> GF // M. Fischer, J. Fritz, C. Kepper, C. Kremers, M. Wenig
>>
>> Kurze Pause gefällig?
>> www.neckermann.de/krimi
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Stripes-development mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Stripes-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-development


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development

Reply via email to