commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: [DynaBean] a couple of other existing projects...
Date Thu, 03 Jan 2002 13:27:12 GMT
From: "Paulo Gaspar" <paulo.gaspar@krankikom.de>
> > > 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.

Agreed. Things like number or date range constraints or String patterns and
other such validations sound like ideal metatdata to add to DynaClass. i.e.
i18n and user context independent constraints. So maybe a DynaClass has a
number of DynaProperties that can be extended to have validation rules etc.

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.

Another way around this could be to pass in some Context object which has-a
Locale, Timezone, maybe a ResourceBundle and the DynaBean and having
getString() / setString() methods that take a Context. Though this seems a
bit clumsy, seperating this stuff out seems cleaner.


> > 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).

I think a simple facade might be cleaner, that takes care of the i18n and
type conversion issues. i.e. a seperation of concerns. The
DynaClass/DynaBean takes care of the typesafe properties and validation
rules, the BeanController (or BeanConverter) takes care of the type
conversion & i18n & validation messages issues. Though maybe adding an
optional Formatter to the DynaProperty/DynaClass might help keep the
metadata together, then just have a single helper class
BeanController/Converter/View to do the i18 specific stuff.

Still thinking aloud though.

> > > 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.

Ah in that case I read them; it was those ideas I was responding to. I was
just checking there wasn't another discussion thread going on some place
else.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message