Answer inline: > ----- Original Message ----- > From: "Paulo Gaspar" <[EMAIL PROTECTED]> > > Extending the DynaClass and using Converters would do most of what you > > describe here. > > I'm arguing for not putting converters/validators in a DynaClass or a > descendant but in a seperate 'controller'.
I agree with you. > > The DynaClass (metadata) part should be the only one having to be > > extended to avoid a complex DynaBean class structure. Then you can have > > helper classes that use the extended metadata information to the tasks > > you talk about (formatting, validation, etc.). > > > > Trying to include these and other concerns in some DynaBean > descendent(s) > > will produce a monster hard to manage class(es). Separating > such concerns > > in separated helper classes with the help of extended metadata will have > > the advantages of: > > - Simpler code; > > - Easier learning of its use (the user does not have to learn > what he is > > not using). > > I agree DynaBean isn't the right place for this, but I don't > think DynaClass > is either - I think a seperate 'controller' is better. Think MVC and that > the DynaBean/Class as the 'model' and a controller mediates between a view > (HTTP request/form or Swing controls). I was talking about extending DynaClass for extended metadata information. Sometimes you have a bean you use in a very restricted scope - like a data entry form - and it might be much simpler to define all its metadata in a single place, including things like validation and conversion rules. For such use it makes sense to have a specialized DynaClass and some helpers, but I am NOT defending this should be included in the "standard" DynaClass. I am just defending that even in such specific case it is not a very good idea to extend the DynaBean. > Since converters would have all kinds of optional contexts associated with > them like Locale, Timezone and other stuff like maybe the user id or > HttpSession, keeping such a controller seperate to the DynaClass, like the > BeanController idea I suggested, would seem cleaner. > > e.g. a single 'customer' DynaBean instance could have a single DynaClass > instance (which could be shared by other customer DynaBeans) but could be > viewed using various different locales & timezones & users. So having a > seperate 'controller' object for each context would seem to make sense, > which just has-a reference to the DynaBean. Sure. But I still defended the option we previously discussed of having a converter attached to the DynaBean object (not the DynaClass) since it can make most of its uses simpler (e.g.: set the bean with a converter for the right Locale and just assign values to its fields). > > Craig, I and others discussed several ideas that have a lot to do with > > this stuff during the last couple of weeks. > > Just out of interest was this on a struts list or just privately? Just here in the commons-dev list. I do not use Struts. > James Have 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]>
