commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <>
Subject RE: [DynaBean] a couple of other existing projects...
Date Thu, 03 Jan 2002 13:16:39 GMT
Answer inline:

> ----- Original Message -----
> From: "Paulo Gaspar" <>
> > 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
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.


But I still defended the option we previously discussed of having a
attached to the DynaBean object (not the DynaClass) since it can make most
its uses simpler (e.g.: set the bean with a converter for the right Locale
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

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message