Hi Ken, see my comments inline:
----- Original Message -----
From: "Kevin A. Roll" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 27, 2004 8:11 PM
Subject: [OS-webwork] Suggestions for WebWork
>
> I would like to propose two enhancements to WebWork related to
> PropertyEditors. In just about every application I write I find the need
to
> display Dates in a standard format. I'm using code something like the
> following:
>
> // First, reference BeanUtil so its static initialization gets run.
> new BeanUtil();
> // Now, reregister our own editor for Dates:
> PropertyEditorManager.registerEditor(Date.class,
> com.anaglyph.util.DateEditor.class);
> PropertyEditorManager.registerEditor(Date[].class,
> com.anaglyph.util.DateEditor.class);
>
> which obviously replaces the registered editor with my own subclass. This
> works great, but I feel a little weird about having to ensure that
BeanUtil
> initializes and so forth. I'd like a standard method to do this properly.
> One thing that worried me was that the FastPropertyEditor would be cached
> and not replaced if I performed this registration too late.
I do the same thing as you do and I agree that it is not very good and I
have also been thinking about adding a register method to BeanUtil for this.
So how about if we add a register method that would take a class and a
FastPropertyEditor instance? It would just put it in the cache of
FastPropertyEditors in the BeanUtil cache, and not register it with the
PropertyEditorManager. Then you can override whatever might be in the cache
already. So it would look something like:
public static FastPropertyEditor registerEditor(Class clazz,
FastPropertyEditor editorInstance)
{
Object editor = propertyEditors.put(clazz, editorInstance);
if (editor instanceof FastPropertyEditor)
return (FastPropertyEditor) editor;
else
return null;
}
>
> The second issue I encountered was that my JDO implementation was
returning
> a bizarre subclass of Date from the business object getters. This confused
> the PropertyEditor system and my subclass was not used to perform the
> format. I had to call registerEditor again with this subclass to get it to
> work. I realize from looking at the code that it would be tricky to have
> the framework fall back on the PropertyEditor that is registered for the
> superclass, but this would be a useful feature.
Perhaps it would be useful but performance would suffer for those cases if
you would have to do multiple lookups for superclasses. Unless you let
Webwork automatically register the class it eventually finds. But then you
also lose some control and perhaps an editor is used even though you do not
want one.
I'd prefer to register editors manually for subclasses.
Best regards,
Dick Zetterberg
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
