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.
<%20http://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar/features/mail/>
-------------------------------------------------------------------------
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
