Answer inline:
> ----- Original Message -----
> From: "Paulo Gaspar" <paulo.gaspar@krankikom.de>
> > 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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|