Answer inline:
> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 03, 2002 2:49 PM
>
> James Strachan wrote:
> > For things like type converters that turn Strings to and from other data
> > types such as Number and Date, I was thinking these converters should be
> > moved to a Controller as they can be environment or framework dependent.
> > e.g. validation might result in a localized message being produced to be
> > displayed in a UI. Or arbitrary formatting rules could be
> applied to display
> > property values.
> >
> > So I was musing about the idea of having a BeanController facade to a
> > DynaBean (or regular JavaBean) that used Strings and was responsible for
> > doing the type conversions and validation messages, having Locale,
> > ResourceBundles and whatnot, seemed better than forcing a DynaClass to
> > understand these i18n issues.
>
> David Winterfeldt's validator (already accepted as a Commons product)
> uses an XML configuration file to store these kind of properties for a
> field.
>
> http://home.earthlink.net/~dwinterfeldt/
Interesting stuff!
=:o)
> This can then be used in collaboration with a controller to perform a
> primia facia validation, and generate localized messages and what not.
>
> This would be the sort of thing that could also be stored with a column
> helper inside the DynaBean. The controller could then run down the
> objects stored in the DynaBean and trigger the validations/conversions,
> rerouting control if one or more fail.
>
> Of course, the DynaBean would not need to be aware of any of this, it is
> just encapsulating the column helpers. The controller could be calling
> the triggers on DynaBean members (which it would know are all column
> helper objects).
>
> I'm thinking we could merge what David's validator does with a column
> helper that also supported a data-entry buffer, and define everything
> about a column in one place. You know, like Access or FileMakerPro ;-)
What I am trying to find out is an as-light-as-possible implementation of
a DynaBean that allows to do all this stuff.
Since this is stuff that depends on a context (what is the Locale of the
user, i18n, current form, etc.) it should be in an external Controller as
James suggested or in the DynaBean as I like (for simple enough stuff).
The DynaClass is one for the whole app. Any properties and rules you set
there are application wide. If you set a DynaClass for a "form bean"
DynaBean, it will probably only be useful for that form - and this could
be very appropriate anyway.
If you have column helpers per DynaClass (as I have for some wrappers)
they are application wide too.
OTOH, If you have column helpers per DynaBean, the DynaBean might become
an heavy object - at least an additional object per property per bean.
Lets evolve a bit the per-property-converter of my previous post and call
it an input filter:
public interface InputFilter
{
Object filter(int propIndex, Class destType, Object newValue);
}
If you have an (optionally doing nothing) InputFilter per DynaBean with
its filter method called to process each value being assigned to a
property you can do a lot with it in terms of per field type conversion
and validation (or you can do nothing).
You can implement an InputFilter to apply generic type conversion rule,
per-property type conversion rules, same thing for validation.
And you can swap InputFilter at each stage of a processing pipeline
depending on the needs of that stage.
You can make it very light:
public class NoOpInputFilter implements InputFilter
{
public final Object filter(int propIndex, Class destType, Object
newValue)
{ return newValue;
}
}
Or you can make it as complex as you describe.
For global bean validation you can implement an extended interface:
public interface PostValidatingInputFilter extends InputFilter
{
void validate(DynaBean updatedBean);
}
Then helper methods or controllers can do things like:
public class DataPumpHelper
{
//...
public static void copyByName(Map source, DynaBean dest)
{
final String[] propNames = dest.propNames();
for(int i = 0; i < propNames.length; ++i)
{ String pName = propNames[i];
if (source.containsKey(pName))
{
dest.set(pName, source.get(pName));
}
else
{
dest.set(pName, null);
}
}
InputFilter inpFilter = dest.inputFilter();
if (inpFilter instanceof PostValidatingInputFilter)
{
((PostValidatingInputFilter)inpFilter).validate();
}
}
//...
}
Of course that both the InputFilter.filter() and the
PostValidatingInputFilter.validate() methods should throw exceptions when
something is wrong/invalid. I am just not very sure if they should be
RuntimeException's but that is what I am doing for data conversion.
The above DataPumpHelper.copyByName() could collect those exceptions to
provide complete information on all that goes wrong.
> The nice part about doing this with a DynaBean, is that we get what
> appears to be a standard JavaBean, but is actually being assembled from
> component objects.
YEEEEEeeeeeeeeeessssssssss!!!!
=:o)
> Again, this would not be in the DynaBean package per se, but another
> package using the DynaBean as a proof of concept.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
Keep the ideas flowing and ave fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
