Struts framework design question: Type Converters and Tags

[jimski <ji...@gmail.com>]

I recently ran into an issue where I noticed that a custom type converter was
being called when parameters were being applied to a model object but not
when that model was being rendered out to a result via the s:select tag. 
The issue is probably summed up by Jasper Rosenberg's previous bug report
WW-2047 (https://issues.apache.org/struts/browse/WW-2047).  After reading
that report I have the following question/observation:

Since XWork's type conversion capabilities are among the best features of
the framework, why are they being subverted by hard-coding the tags so that
they only call toString, even in the presence of a custom type converter. 
The response in the Jira issue was to make sure toString returned what we
wanted.  The trouble with that is now the web framework is dictating how the
model classes are designed...  and wasn't getting away from that kind of
problem one of the major benefits of moving to s2?  The type converters are
there explicitly to provide flexibility to the framework so that the
framework designer's assumptions don't end up hamstringing the applications
being written on top of the framework.

Just how difficult would it be for the tags to look for a type converter
first (since the appropriate call in this circumstance would be returning a
string) and then fail back to toString if one was not found?  Wouldn't that
approach be more in keeping with the spirit of the framework?


-- 
View this message in context: http://www.nabble.com/Struts-framework-design-question%3A-Type-Converters-and-Tags-tp15019888p15019888.html
Sent from the Struts - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Struts framework design question: Type Converters and Tags

[Ted Husted <hu...@apache.org>]

I'm not sure how difficult it would be to have the tags look for a
type converter first, but if you can come up with a working patch, I'd
be happy to review it.

HTH, Ted

On Jan 22, 2008 9:41 AM, jimski <ji...@gmail.com> wrote:
>
> I recently ran into an issue where I noticed that a custom type converter was
> being called when parameters were being applied to a model object but not
> when that model was being rendered out to a result via the s:select tag.
> The issue is probably summed up by Jasper Rosenberg's previous bug report
> WW-2047 (https://issues.apache.org/struts/browse/WW-2047).  After reading
> that report I have the following question/observation:
>
> Since XWork's type conversion capabilities are among the best features of
> the framework, why are they being subverted by hard-coding the tags so that
> they only call toString, even in the presence of a custom type converter.
> The response in the Jira issue was to make sure toString returned what we
> wanted.  The trouble with that is now the web framework is dictating how the
> model classes are designed...  and wasn't getting away from that kind of
> problem one of the major benefits of moving to s2?  The type converters are
> there explicitly to provide flexibility to the framework so that the
> framework designer's assumptions don't end up hamstringing the applications
> being written on top of the framework.
>
> Just how difficult would it be for the tags to look for a type converter
> first (since the appropriate call in this circumstance would be returning a
> string) and then fail back to toString if one was not found?  Wouldn't that
> approach be more in keeping with the spirit of the framework?

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org