Hi
If we're going that direction, and I admit that sometimes would be nice to
have access to Stripes request related stuff easily, then I think a
ThreadLocal where we can have access to stuff like current ActionBeanContext
(which gives Request and Locale) and the ActionBean being called (like we
have in the ExecutionContext for Interceptors) would be a good candidate.
Thoughts?
/Jeppe
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Barry Davies
Sent: 29. maj 2007 15:40
To: Stripes Development List
Subject: Re: [Stripes-dev] stripes:param should use formatters when possible
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
<http://www.youtube.com/watch?v=na2W38tLp_Q> Snatchers
point-and-gutteral-noise (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]>
To: Stripes Development List <[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]>
To: Stripes Development List <[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] 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:stripes-
[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]
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]
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]
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
_____
It's here! Your new message!
Get new email alerts
<http://us.rd.yahoo.com/evt=49938/*http:/tools.search.yahoo.com/toolbar/feat
ures/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]
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
_____
Park yourself in front of a world of choices in alternative vehicles.
Visit
<http://us.rd.yahoo.com/evt=48246/*http:/autos.yahoo.com/green_center/;_ylc=
X3oDMTE5cDF2bXZzBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDZ3JlZW4tY2VudGVy>
the Yahoo! Auto Green Center.
__________ NOD32 2295 (20070529) 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]
https://lists.sourceforge.net/lists/listinfo/stripes-development
