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

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&op=click
_______________________________________________
Stripes-users mailing list
hidden
https://lists.sourceforge.net/lists/listinfo/stripes-users