Re: [Stripes-users] stripes:hidden malfunction ?

Subject:   Re: [Stripes-users] stripes:hidden malfunction ? (find more)
From:   Lukas Vlcek <hidden> (find more)
Date:   Dec 23, 2005 01:48

Hi Tim,

I will use request wrapper for now as it perfectly fits into my
situation (because I know that when going to one specific JSP page I
need to remove specific parameters from URL no matter who is
requesting it and when).

The only think I don't like is that this way I will implement some
application logic in servlet filter, I'd rather see it implemented
somwhere *more inside the application* and not in servlet filter.

As for the flash scope I don't fully understand the idea but if you
say that then it must be cool :-) Thanks for your time and keep
stripes movin'. I like it!!!

Lukas

On 12/22/05, Tim Fennell <hidden> wrote:
> I'd actually started writing you another email on this topic then got
> dragged off to lunch!
>
> For a request wrapper I think what I'd do is hold a second map of
> request parameters, and implement a remove method to insert a null
> into this second map under the appropriate key.  Override values
> would work the same way, by inserting a new key/value into the Map.
> Then methods like getParameter() getParameterValues()  could be
> implemented as fall-throughs (get from my Map, if the key isn't
> present call super). getParameterMap()  would be a simple
> super.getParameterMap().removeAll(myMap).  I think that'd probably be
> the cleanest/most efficient way to do it, rather than copying
> parameters around everywhere.
>
> The other option, which I'm more interested in implementing in
> Stripes is the idea of a "flash scope".  The idea here is that you
> make it easier to do redirect-after-post so that you work right
> around your problem. A bean puts things into "flash" scope in one
> request.  The flash scope is really just a walled off section of
> HttpSession.  Then, you redirect the browser and use a Filter
> (preferably) to yank things out of flash scope and put them back into
> request attributes.  Using this solution you can re-direct, tack on
> any request parameters you like from the original request, and put
> whatever you need for the page into "flash scope"...
>
> -t
>
> On Dec 22, 2005, at 12:23 PM, Lukas Vlcek wrote:
>
> > Tim,
> >
> > That would be probably useful.
> >
> > I'll try to explain what exactly I need to solve. I am working on web
> > application which uses both stripes and displaytag. Sometimes it leads
> > to problems. I am able to null some properties in action (which are
> > now populated from regular non-stripes input:hidden tags) but the
> > problem is that they are part of URL (url parameters) and as a such
> > they are send back to JSP page via forward.
> > On the JSP page I can ignore them when using regular html <input
> > type=hidden name=foo value=${foo}/> approach but the problem is with
> > displaytag as it renders a lot of links (for pagination for example)
> > and it just uses the original URL which was returned from action. This
> > mean that listing among table pages repeates also unwanted
> > functionality in action.
> >
> > Thus what I need is probably a servlet filter which will be used once
> > stipes action forward to target JSP and it will perform some cleaning
> > on url parameters. Is that possible? If yes then what methods I need
> > to override in HttpServletRequestWrapper interface (as all I need is
> > to remove several parameters at that point).
> >
> > Anyway, thanks a lot!
> > Lukas
> >
> > On 12/22/05, Tim Fennell <hidden> wrote:
> >> Well,
> >>
> >> There's a couple of things here.  The thought was to come up with a
> >> strategy that is easy to understand and somewhat bullet-proof.  I
> >> made the decision early on to try and come up with a strategy that
> >> would work for most normal cases *and* when re-rendering pages with
> >> validation errors.  In the latter case you may not have been able to
> >> bind everything into the ActionBean, so you'd want to pull from the
> >> request.
> >>
> >> If you decide that the ActionBean takes precedence, then you have to
> >> deal with the cases where the action bean has no value, but the
> >> request does.  In many cases that'll be because binding failed or
> >> some similar reason.  In other cases it might be because the
> >> developer in question null-ed out the action bean property.
> >>
> >> On the other hand, the current version of Stripes wraps all of the
> >> re-
> >> population logic up in to a class that implements
> >> PopulationStrategy.  The only thing I haven't done to round that out
> >> yet is to make that class pluggable through configuration (but that
> >> won't be hard).  That way, if you don't like the way that Stripes
> >> handles repopulation, you'd be able to extend or replace the default
> >> strategy to meet your needs more closely.  Hopefully that would pop
> >> open an escape valve for anyone that needs it.
> >>
> >> -t
> >>
> >> On Dec 22, 2005, at 11:12 AM, Lukas Vlcek wrote:
> >>
> >>> Tim,
> >>>
> >>> Using *plain old* html hidden input tag should work I think.
> >>> I was so stripes centric that I didn't think of using other
> >>> possibilities :-)
> >>> Thanks for tip, I'll give it a try.
> >>>
> >>> Anyway, do you have any reason why you choose the specific order of
> >>> re-population strategy? Let's say I can make workaround for now
> >>> using
> >>> directly html input tag and leaving stripes away. But what if I
> >>> can't
> >>> leave stripes out the next time? I just won't be able to get desired
> >>> functionality with stripes! Doesn't this scare you? ;-D
> >>>
> >>> Lukas
> >>>
> >>> On 12/22/05, Tim Fennell <hidden> wrote:
> >>>> Hey Lukas,
> >>>>
> >>>> Right now there is no way to do what you want to do with the
> >>>> Stripes
> >>>> hidden field tag.  But, I think the simplest solution by far would
> >>>> just be to use a non-stripes hidden field.  The Stripes tags
> >>>> follow a
> >>>> strict re-population strategy that accepts the first non-null value
> >>>> found in the following order:
> >>>>         - HttpRequest parameters
> >>>>         - ActionBean properties
> >>>>         - Default values on the JSP
> >>>>
> >>>> But it sounds like what you're doing doesn't really need any of the
> >>>> "value-add" properties of the stripes:hidden tag like auto-
> >>>> repopulation under error etc.  More like you just want it to always
> >>>> hold a specific value from a bean in request scope.  In that
> >>>> case I'd
> >>>> just write:
> >>>>         <input type="hidden" name="foo" value="${foo}"/>
> >>>> and leave it at that.  Will this work for you?
> >>>>
> >>>> -t
> >>>>
> >>>> On Dec 22, 2005, at 8:48 AM, Lukas Vlcek wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I am experiencing strange behavior of stripes:hidden tag. I am not
> >>>>> sure if this is a bug or correct behavior, anyway here is the
> >>>>> problem
> >>>>> description:
> >>>>>
> >>>>> I have a form on my JSP with hidden input foo. I populate its
> >>>>> value
> >>>>> from javascript (form.foo.value = 'XYZ';) and then I call
> >>>>> form.submit().
> >>>>>
> >>>>> Thus request with URL parameter foo=XYZ is created and sent to
> >>>>> action.
> >>>>>
> >>>>> In action I get value of foo and then I reset foo (setFoo("")) and
> >>>>> store *empty* foo value in request. Then forward to JSP. It is
> >>>>> important to note that it is the same/original JSP.
> >>>>>
> >>>>> In JSP I have something like
> >>>>> <c:out value="${foo}"/>
> >>>>> <stripes:hiddne name="foo" value="${foo}">
> >>>>>
> >>>>> It is clear that there is still URLparameter foo=XYZ in the
> >>>>> request.
> >>>>> However foo value stored in request score is empty (which I
> >>>>> proved by
> >>>>> <c:out value="${foo}"/>) but hidden input does not reflects
> >>>>> that and
> >>>>> it takes the value from URL parameter. So the hidden input
> >>>>> value of
> >>>>> foo is still XYZ which I don't think is correct.
> >>>>>
> >>>>> Interestingly, I found that if there is <stripes:hiddne name="foo"
> >>>>> value="dummy"> in JSP and this JSP is called with foo URL
> >>>>> parameter
> >>>>> (again it can be foo=XYZ), then this hidden value is overriden. It
> >>>>> results to <input type=hidden name='foo' value='XYZ'> instead of
> >>>>> <input type=hidden name='foo' value='dummy'>.
> >>>>>
> >>>>> This seems very confusing to me.
> >>>>>
> >>>>> Is there any way how make stripes:hidden tag reflect the real
> >>>>> value of
> >>>>> request scoped ${foo} instead of foo=XYZ URL parameter?
> >>>>>
> >>>>> Regards,
> >>>>> Lukas
> >>>>>
> >>>>>
> >>>>> -------------------------------------------------------
> >>>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> >>>>> log files
> >>>>> for problems?  Stop!  Download the new AJAX search engine that
> >>>>> makes
> >>>>> searching your log files as easy as surfing the  web.  DOWNLOAD
> >>>>> SPLUNK!
> >>>>> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> >>>>> _______________________________________________
> >>>>> Stripes-users mailing list
> >>>>> hidden
> >>>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------
> >>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> >>>> log files
> >>>> for problems?  Stop!  Download the new AJAX search engine that
> >>>> makes
> >>>> searching your log files as easy as surfing the  web.  DOWNLOAD
> >>>> SPLUNK!
> >>>> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> >>>> _______________________________________________
> >>>> Stripes-users mailing list
> >>>> hidden
> >>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
> >>>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> >>> log files
> >>> for problems?  Stop!  Download the new AJAX search engine that makes
> >>> searching your log files as easy as surfing the  web.  DOWNLOAD
> >>> SPLUNK!
> >>> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> >>> _______________________________________________
> >>> Stripes-users mailing list
> >>> hidden
> >>> https://lists.sourceforge.net/lists/listinfo/stripes-users
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> >> log files
> >> for problems?  Stop!  Download the new AJAX search engine that makes
> >> searching your log files as easy as surfing the  web.  DOWNLOAD
> >> SPLUNK!
> >> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> >> _______________________________________________
> >> Stripes-users mailing list
> >> hidden
> >> https://lists.sourceforge.net/lists/listinfo/stripes-users
> >>
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through
> > log files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD
> > SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> > _______________________________________________
> > Stripes-users mailing list
> > hidden
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> _______________________________________________
> Stripes-users mailing list
> hidden
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Stripes-users mailing list
hidden
https://lists.sourceforge.net/lists/listinfo/stripes-users
Entire Thread (Showing 4 of 11)

  • Re: [Stripes-users] stripes:hidden malfunction ? Lukas Vlcek <hidden>

    Tim, That would be probably useful. I'll try to explain what exactly I need to solve. I am working on web application which uses both stripes and displaytag. Sometimes it leads to problems. I am able to null some ...

    • Re: [Stripes-users] stripes:hidden malfunction ? Tim Fennell <hidden>

      I'd actually started writing you another email on this topic then got dragged off to lunch

      • Re: [Stripes-users] stripes:hidden malfunction ? Lukas Vlcek <hidden>

        • Re: [Stripes-users] stripes:hidden malfunction ? Nic Holbrook <hidden>

          I have been following this little discussion a bit but didn't pay much interest until I ran into the same problem. I would think if you set a value in the jsp tag, that would take precedence over the request and bean ... (2 more messages in this thread)