commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Wohl <>
Subject Re: [BeanUtils] populate problem
Date Thu, 24 Apr 2003 07:35:39 GMT
Oh, there's one more item.

d) Track object id's back and forth across forms.

   Back to the example, we want to allow the user Javascript-expansion of
   objects on the page.  From simple "grow this list of names" (one field per)
   to "add more of this complex outer type" (with various sub-growth).

   We don't really need to know these are complex objects.  Field sets of the

   mean, if we haven't seen loans[1] yet, we need to create it, and go on
   our merrying setting way.

   However, object id's need to get tracked.  In our case, objects have GUIDs
   generated by the persistence layer.  Let's say we showed the user three loans,
   and they've added two more.  We need to map existing field sets (objects) back
   to their original GUIDs, and zero out those for new objects.  I'm sure the
   easiest method is just to keep ordering the same in lists, or round-trip
   these ids in hidden form fields.

   I mention it, in case someone has a better idea that can be generically


On Thu, Apr 24, 2003 at 03:20:56AM -0400, Jeremy Wohl wrote:
> On Wed, Apr 23, 2003 at 09:42:17PM +0100, robert burrell donkin wrote:
> > i'm very cautious about adding functionality (and i think that other 
> > beanutils committers feel similarly.) i'd prefer a well thought out 
> > solution rather than something that just gets the job done.
> Roger.  Let me explain our current needs -- needs which must be met in
> the next few weeks, so I'll have working code if we come to consensus
> about a solution.
> a) Create intermediate nodes of a nested path, where null.  Discover
>    "opaque" types (i.e. those behind Maps and Lists) via explicit BeanInfo-like
>    descriptors.
>    I see {Mapped,Indexed}PropertyDescriptor in BeanUtils, with a class
>    type attribute.  What was the intention here?  And Clazz has similar
>    metadata.
> b) Fill gaps in type conversion with respect to mapped/indexed properties.
>    Related to (a).
> c) Support factories for said node creation, specified in the type-local
>    descriptors.
>    One of my requirements is to instantiate specific subtypes based on
>    fields in the user input (e.g. a code field determines a particular
>    child of Fruit.)  Would be handy to have this happen as part of the
>    same node creation.  So we pass parameters to a constructor .. perhaps
>    just the parent object.  If a factory is unspecificed, we call the
>    default constructor or newInstance().
> Thoughts?
> thanks,
> -jeremy
> _____________________________________________________________________
> jeremy wohl ..:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

jeremy wohl ..:

View raw message