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