On Tue, 21 Dec 2004 10:15:26 +0530, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
