You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by mo...@accenture.com on 2004/12/21 05:45:26 UTC
Struts converters
Hi,
A new chapter from a Struts book has been posted to TSS. It seems
that the solution for automatic conversion and formatting is already there
in the form of java bean PropertyEditors.
Why isn't Struts ( Shale ? ) proposing the use of PropertyEditors ( like
Spring )? Is it too much change to the Struts codebase ?
Doesn't this solution from the book duplicate what Java beans can do ?
Thanks,
Mohan
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete the
original. Any other use of the email by you is prohibited.
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts converters
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 21 Dec 2004 10:15:26 +0530, mohan.radhakrishnan@accenture.com
<mo...@accenture.com> wrote:
> Hi,
> A new chapter from a Struts book has been posted to TSS. It seems
> that the solution for automatic conversion and formatting is already there
> in the form of java bean PropertyEditors.
>
The PropertyEditor is, umm, err, designed to edit properties, not
convert values :-). Yes, it includes methods that could be used for
the conversions, but they include other (undesireable) things as
discussed further below.
> Why isn't Struts ( Shale ? ) proposing the use of PropertyEditors ( like
> Spring )? Is it too much change to the Struts codebase ?
For Struts 1.x, changing the existing codebase would be a significant
issue by itself, but there is an even more important reason that
PropertyEditor was not used originally -- the API includes methods
like isPaintable() and paintValue() that refer to AWT APIs. In a very
large number of server side deployments on Unix systems, there will be
no X server running (to avoid overhead, but also to avoid potential
security related attacks through X's networking support). Therefore,
references to a pretty large number of the AWT APIs will throw
exceptions instead of doing something useful. If you can convince
your sysadmin that it's safe, this can partly be worked around by
using things that "fake" an X presence, but it's a lot more
configuration hassle than it's worth.
For Shale, the whole point is to build on top of JSF -- which already
has very nicely tuned conversion APIs, and which rejected using
PropertyEditor for pretty much the reasons described above.
> Doesn't this solution from the book duplicate what Java beans can do ?
Although you can *technically* use PropertyEditor for things like
this, there is another subtle difference -- PropertyEditor, like many
of the other JavaBeans APIs, is focused on what happens at *design*
time inside a tool. The conversions we are talking about here are
things that happen at *runtime*, inside a server. Design time APIs
should stay at design time, so you don't have to carry along those
implementations at runtime.
>
> Thanks,
> Mohan
Craig
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the email by you is prohibited.
>
> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts converters
Posted by Joe Germuska <Jo...@Germuska.com>.
I only briefly skimmed the chapter. I think that struts isn't
proposing the use of property editors because no one has identified
this as such a serious shortcoming of the current system. Maybe the
author speaks for more people than I realize, but personally, I don't
find the current model terribly burdensome.
I'm not familiar with how Spring uses PropertyEditors -- are you just
talking about taking advantage of an interface for converting strings
to other types? Or about some more elaborate use? As the article
notes, all property conversion is delegated by Struts to
commons-beanutils. I'm not sure what original design decisions went
into not using PropertyEditors in beanutils, but I do find Converters
much simpler to implement than PropertyEditors!
It's probably a fair request to ask that BeanUtils honor
PropertyEditors where they are defined -- I'm pretty sure it doesn't
now -- but even if it "duplicates what Java beans can do", I think
the java.beans.* APIs are generally way overblown for most non-tool
uses.
If you think BeanUtils should honor PropertyEditors, i'd suggest
posting a request in Bugzilla:
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commons
Joe
At 10:15 AM +0530 12/21/04, <mo...@accenture.com> wrote:
>Hi,
> A new chapter from a Struts book has been posted to TSS. It seems
>that the solution for automatic conversion and formatting is already there
>in the form of java bean PropertyEditors.
>
>Why isn't Struts ( Shale ? ) proposing the use of PropertyEditors ( like
>Spring )? Is it too much change to the Struts codebase ?
>
>Doesn't this solution from the book duplicate what Java beans can do ?
>
>Thanks,
>Mohan
>
>
>
>This message is for the designated recipient only and may contain
>privileged, proprietary, or otherwise private information. If you have
>received it in error, please notify the sender immediately and delete the
>original. Any other use of the email by you is prohibited.
>
>
>
>This message is for the designated recipient only and may contain
>privileged, proprietary, or otherwise private information. If you
>have received it in error, please notify the sender immediately and
>delete the original. Any other use of the email by you is
>prohibited.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org