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

Subject:   Re: [Stripes-users] stripes:hidden malfunction ? (find more)
From:   Nic Holbrook <hidden> (find more)
Date:   Dec 28, 2005 16:55

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 properties.  If I do a
<stripes:hidden name="user.userId"
value="${manageUsers.userId}" />

I would expect my value to override everything.  I
could see the request or bean properties being default
if I don't have a value set as in
<stripes:hidden name="user.userId"/>

Maybe I'm missing something here.

Nic

--- Lukas Vlcek <hidden> wrote:

> 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
>
=== message truncated ===



  
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com



-------------------------------------------------------
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_id=7637&alloc_id=16865&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 ? 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>

      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 ...

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

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

          Hmm. I find that I often want things the other way around. I often use the value="" attribute on the JSP to supply a default value for that field, knowing that it will be overridden if/when the page is rendered with user input present in the request, or information ... (1 more message in this thread)