I'm a little confused. Are you saying we should add 
OnwardResolution.getUrl(Locale) but move the stuff that does the 
formatting into UrlBuilder? That would also require a change to 
UrlBuilder because it doesn't use a Locale in its current form. Should 
we just add a UrlBuilder.setLocale(Locale)? New constructor?

Tim Fennell wrote:
> So I  just took a look at the code in SVN, and I think it's definitely 
> doable to make this work in UrlBuilder.
>
> My suggestion would be that we add a method to OnwardResolution that 
> looks like:
> String getUrl(Locale local);
>
> And that we deprecate the existing getUrl(), and have it call through 
> with the system default locale.  We should probably also change both 
> of these methods to protected (I'm not sure why I made them public).  
> The only places getUrl() is called right now are in subclasses, inside 
> the execute() method which has access to both the request and 
> response, and could therefore supply the Locale easily enough.
>
> -t
>
> On May 29, 2007, at 9:40 AM, Barry Davies wrote:
>
>> Ben, I ran into the exact same problem when I tried to prepare a 
>> patch for the issue.  I posted to the boards with the exact same 
>> question, but didn't get alot of replies.  I was thinking about 
>> creating a ThreadLocal registry for the Locale (or maybe even the 
>> entire session), and exposing that as another convenience feature of 
>> Stripes.  But I'm not a strict test-driven development kinda guy, so 
>> I didn't know whether that was the sort of thing that would cause Tim 
>> to do the Invasion of the Body Snatchers point-and-gutteral-noise 
>> <http://www.youtube.com/watch?v=na2W38tLp_Q> (1:50 into the clip) 
>> when he saw my patch.  I'm still leaning toward thinking it'd be a 
>> good idea to expose a ThreadLocal Session Registry from Stripes as a 
>> convenience feature, and it would assist in the resolution of this 
>> issue.  I understand that this registry would become something that 
>> ever single test would have to mock into existence, because you never 
>> know when something is using it.  What do you think?
>>
>> -BD aka RJ
>>
>> ----- Original Message ----
>> From: Ben Gunter <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>> To: Stripes Development List 
>> <[email protected] 
>> <mailto:[email protected]>>
>> Sent: Monday, May 28, 2007 11:14:37 PM
>> Subject: Re: [Stripes-dev] stripes:param should use formatters when 
>> possible
>>
>> There's a small problem. I made this change for s:url and s:link. I 
>> did so by changing LinkTagSupport.buildUrl() to copy the parameter 
>> map, format each value, and then call UrlBuilder.addParameters().
>>
>> I know I could have changed UrlBuilder.addParameter[s] to do the 
>> formatting. I opted not to because I figured it might be better to 
>> let UrlBuilder remain more of a utility class that has no 
>> Stripes-specific dependencies. I don't know if that's a valid reason. 
>> If y'all think it might be better to have UrlBuilder do the 
>> formatting then I can change it easily enough.
>>
>> The reason it might be good to do it in UrlBuilder is because it 
>> could be done once and fix s:link, s:url, and OnwardResolution all at 
>> once. But I went to fix OnwardResolution and realized that it doesn't 
>> have access to the Locale. The tags can get it from 
>> pageContext.getRequest().getLocale(), but the OnwardResolution 
>> doesn't have a reference to a request object and so can't get the 
>> Locale to pass into Formatter.format(). Any suggestions on how to get 
>> around this?
>>
>> -Ben
>>
>> Tim Fennell wrote:
>>> Yes, I agree.
>>> -t
>>>
>>> On May 28, 2007, at 3:08 PM, Barry Davies wrote:
>>>
>>>> Agreed, having <s:param> (or <s:link>) use formatters by default 
>>>> sounds like the most dev-friendly option to me.  Of course, all of 
>>>> this still leaves out the fact that OnwardResolution.addParameter 
>>>> also doesn't use the formatters.  Formatters-in-param-tag was 
>>>> mentioned also in STS-322 <http://mc4j.org/jira/browse/STS-322>, 
>>>> that I logged awhile ago.  Does anyone else agrees that there 
>>>> should be a symmetry between <s:param> and 
>>>> OnwardResolution.addParameter()?
>>>> -BD aka RJ
>>>>
>>>> ----- Original Message ----
>>>> From: Tim Fennell <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>>>> To: Stripes Development List 
>>>> <[email protected] 
>>>> <mailto:[email protected]>>
>>>> Sent: Monday, May 28, 2007 8:37:00 AM
>>>> Subject: Re: [Stripes-dev] stripes:param should use formatters when 
>>>> possible
>>>>
>>>> I think I'm a bit late to the game on this one, since the commit 
>>>> email have already flown.  I definitely like the s:format tag - I 
>>>> think it's a great addition.
>>>>
>>>> But I'm also wondering if it wouldn't be best to use the formatting 
>>>> engine, with default style/pattern information, as the default way 
>>>> of rendering objects to Strings in the param tags?  I can't really 
>>>> think of a reason that this would be worse than the current way 
>>>> (just toString()ing things), but it would also make life easier in 
>>>> a lot of cases.
>>>>
>>>> I think the major reason this was brought up was in the Stripernate 
>>>> (or similar) pattern where you might have links like:
>>>>     <s:link href="/Edit.action">
>>>>         <s:param name="id" value="${person.id}"/>
>>>>     </s:slink>
>>>>
>>>> If I recall correctly, then folks ended up implementing a lot of 
>>>> toString() methods to return IDs - and that's less than ideal for 
>>>> several reasons.  The new solution (with format tag) would 
>>>> obviously work here, but it starts to get a bit verbose and 
>>>> repetitive if you don't really need to provide the additional 
>>>> formatting parameters:
>>>>     <s:link href="/Edit.action">
>>>>         <s:param name="id"><s:fomat value="${person.id}"/></s:param>
>>>>     </s:slink>
>>>>
>>>> So what do you think about using the formatters with their default 
>>>> configurations as the default way to turn Object->String in the 
>>>> param tag (actually, probably s:link tag)?
>>>>
>>>> -t
>>>>
>>>>
>>>> On May 27, 2007, at 1:45 PM, Jeppe Cramon wrote:
>>>>
>>>>> Hi
>>>>>
>>>>>  
>>>>>
>>>>> Option 1 sounds good and is as Kai says useful in other 
>>>>> circumstances too :)
>>>>>
>>>>>  
>>>>>
>>>>> /Jepe
>>>>>
>>>>>  
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> *From:* [EMAIL PROTECTED] 
>>>>> <mailto:[EMAIL PROTECTED]> 
>>>>> [mailto:[EMAIL PROTECTED] *On 
>>>>> Behalf Of *Ben Gunter
>>>>> *Sent:* 26. maj 2007 19:03
>>>>> *To:* Stripes Development List
>>>>> *Subject:* Re: [Stripes-dev] stripes:param should use formatters 
>>>>> when possible
>>>>>
>>>>>  
>>>>>
>>>>> I knew there had to be more to this story :)
>>>>>
>>>>> As it turns out, if you use s:param in the form:
>>>>>
>>>>> <s:param name="x">${someObject}</s:param>
>>>>>
>>>>> Then the tag's body content is only available as a String. There's 
>>>>> no way to apply a formatter to it because it gets evaluated ahead 
>>>>> of time by the JSP engine. On the other hand...
>>>>>
>>>>> <s:param name="x" value="${someObject}" />
>>>>>
>>>>> Does pass the Object into setValue so a Formatter could be used 
>>>>> there. The problem with that is that the s:param tag is expected 
>>>>> to pass the original Object value to its parent tag, not 
>>>>> necessarily just a String. That means it's up to the parent tag to 
>>>>> format it correctly. And the problem with /that/ is that some 
>>>>> formatters require a format pattern and/or format type, and that 
>>>>> bit of information might be different for each parameter.
>>>>>
>>>>> So we're left with a few choices...
>>>>>
>>>>>    1. Add a new tag <s:format value="" [var=""] [formatType=""]
>>>>>       [formatPattern=""] />. One could then use it like <s:param
>>>>>       name="x"><s:format value="${someObject}" /></s:param>
>>>>>    2. Add some new attributes to s:param, such as format="true",
>>>>>       formatType="whatever" and formatPattern="whatever".
>>>>>       format="true" would be assumed if either formatType or
>>>>>       formatPattern were non-null. If formatType and formatPattern
>>>>>       are not applicable for a given parameter, then format="true"
>>>>>       would be required as the default would be false.
>>>>>    3. Do nothing. I don't like this idea :)
>>>>>
>>>>> I really like option (1). This would be a good idea because it is 
>>>>> useful in many different situations and allows developers to take 
>>>>> full advantage of Stripes' formatting capabilities from within 
>>>>> their JSPs. Imagine this, given a Person class with firstName and 
>>>>> lastName properties:
>>>>>
>>>>>     * <s:format formatType="lastNameFirst" value="${person}" /> --
>>>>>       Gunter, Ben
>>>>>     * <s:format formatType="normal" value="${person}" /> -- Ben Gunter
>>>>>     * <s:format value="${person}" /> -- the primary key of the
>>>>>       object, which is the default format
>>>>>
>>>>>
>>>>> I'll do this if nobody is opposed to the idea. It solves the 
>>>>> s:param problem nicely and provides lots of other useful capabilities.
>>>>>
>>>>> -Ben
>>>>>
>>>>> Jeppe Cramon wrote:
>>>>>
>>>>> No, I agree :)
>>>>>   
>>>>> /Jeppe
>>>>>   
>>>>>  
>>>>>  
>>>>>> -----Original Message-----
>>>>>> From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> [mailto:stripes-
>>>>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>] On Behalf Of Ben Gunter
>>>>>> Sent: 26. maj 2007 02:38
>>>>>> To: Stripes Development List
>>>>>> Subject: [Stripes-dev] stripes:param should use formatters when possible
>>>>>>   
>>>>>> Does anybody disagree with this?
>>>>>>   
>>>>>> http://mc4j.org/jira/browse/STS-374
>>>>>>   
>>>>>> -------------------------------------------------------------------------
>>>>>> This SF.net email is sponsored by DB2 Express
>>>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>>>> control of your XML. No limits. Just data. Click to get it now.
>>>>>> http://sourceforge.net/powerbar/db2/
>>>>>> _______________________________________________
>>>>>> Stripes-development mailing list
>>>>>> [email protected] 
>>>>>> <mailto:[email protected]>
>>>>>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>>>>>   
>>>>>> __________ NOD32 2292 (20070525) Information
>>>>>>  __________
>>>>>>   
>>>>>> This message was checked by NOD32 antivirus system.
>>>>>> http://www.eset.com
>>>>>>     
>>>>>   
>>>>>   
>>>>>   
>>>>> -------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by DB2 Express
>>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>>> control of your XML. No limits. Just data. Click to get it now.
>>>>> http://sourceforge.net/powerbar/db2/
>>>>> _______________________________________________
>>>>> Stripes-development mailing list
>>>>> [email protected] 
>>>>> <mailto:[email protected]>
>>>>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>>>>   
>>>>>
>>>>>
>>>>>
>>>>> __________ NOD32 2292 (20070525) Information __________
>>>>>
>>>>> This message was checked by NOD32 antivirus system.
>>>>> http://www.eset.com
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by DB2 Express
>>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>>> control of your XML. No limits. Just data. Click to get it now.
>>>>> http://sourceforge.net/powerbar/db2/_______________________________________________
>>>>> Stripes-development mailing list
>>>>> [email protected] 
>>>>> <mailto:[email protected]>
>>>>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by DB2 Express
>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>> control of your XML. No limits. Just data. Click to get it now.
>>>> http://sourceforge.net/powerbar/db2/
>>>> _______________________________________________
>>>> Stripes-development mailing list
>>>> [email protected] 
>>>> <mailto:[email protected]>
>>>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> It's here! Your new message!
>>>> Get new email alerts 
>>>> <http://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar/features/mail/>
>>>>  
>>>> with the free Yahoo! Toolbar.
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by DB2 Express
>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>> control of your XML. No limits. Just data. Click to get it now.
>>>> http://sourceforge.net/powerbar/db2/_______________________________________________
>>>> Stripes-development mailing list
>>>> [email protected] 
>>>> <mailto:[email protected]>
>>>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by DB2 Express
>>> Download DB2 Express C - the FREE version of DB2 express and take
>>> control of your XML. No limits. Just data. Click to get it now.
>>> http://sourceforge.net/powerbar/db2/
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Stripes-development mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>>   
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Stripes-development mailing list
>> [email protected] 
>> <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>
>>
>> ------------------------------------------------------------------------
>> Park yourself in front of a world of choices in alternative vehicles.
>> Visit the Yahoo! Auto Green Center. 
>> <http://us.rd.yahoo.com/evt=48246/*http://autos.yahoo.com/green_center/;_ylc=X3oDMTE5cDF2bXZzBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDZ3JlZW4tY2VudGVy>
>>  
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/_______________________________________________
>> Stripes-development mailing list
>> [email protected] 
>> <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Stripes-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-development
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development

Reply via email to