commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@blueyonder.co.uk>
Subject Re: [BeanUtils] WrapDynaBean Enhacement Request
Date Wed, 07 Jan 2004 05:44:42 GMT
My problem is I built a framework to just generate, process and spit out
DynaBeans and then got it to also do POJ beans afterwards when I discovered
your "Wrapped" DynaBeans .

1) WrapDynaClass.newInstance()
The framework generates DynaBeans (from Excel files). I am storing the
DynaClasses and using newInstance() to generate DynaBeans as it needs them.
It just made adapting my framework to generate ordinary JavaBeans via
"Wrapped" dynabeans v.easy with WrapDynaClass.newInstance() working the same
as other DynaClasses. I agree with you, if I hadn't built it initiallly just
for DynaBeans I could have done it differently.

Also if WrapDyanClass doesn't implement the newInstance() method then it
doesn't fulfill its contract as a DynaClass type - shouldn't it do it
anyway, even if there are other ways to generate the WrapDynaBean -
otherwise it has to be catered for as special case.

2) WrapDynaBean.getInstance()
The framework runs out of the box to generate DynaBeans from Excel
spreadsheets using XML configuration. If I can get the original JavaBean out
of the Wrapper, I don't have to worry about modifying my existing framework.
I think this is a good use case - have a system where you can plug in a
Factory to generate whatever flavor of DynaBeans are required, process them
and then spit them out to a downstreams system (which has no reference to
those POJ Beans) which can then "UnWrap" them and use them as it likes.

Thanks for your time and comments.

Niall

> Quoting Craig R. McClanahan <craigmcc@apache.org>>
> >
> > 1+2 it seemed clear that craig intended no constructors to be available
> > (and he usually has good reasons for his design decisions) but i think
> > that allowing WrapDynaClass and WrapDynaBean to fit better into
> > DynaBean frameworks seems like a strong argument for providing this
> > functionality. unless someone else speaks up, i'll likely commit
> > something along these lines.
> >
>
> This design was indeed deliberate.  Whether it makes sense is certainly
open to
> discussion :-).
>
> The design intent for WrapDynaBean{,Class} was that you'd create new
> WrapDynaBean instances by saying:
>
>   Object aJavaBean = ...;
>   DynaBean db = new WrapDynaBean(aJavaBean);
>
> which (if it hasn't been done already) causes a WrapDynaBeanClass instance
to be
> created for you ... 1:1 with the underlying Class instance.  I don't see a
> compelling need for making the WrapDynaBeanClass constructor public, but
> wouldn't be opposed to that if there was a good use case.
>
> For WrapDynaClass.newInstance(), though, it doesn't make sense to ask for
a new
> instance of WrapDynaBean without having it already wrapping some real
bean --
> and there's no way to specify one without a new method signature on
newInstance
> that passes in the bean to be wrapped.  Doesn't that tie you very closely
to
> this particular implementation of DynaBean?
>
> Same argument applies to WrapDynaBean.getInstance() -- I'm not strongly
opposed
> to that, but my thinking was, once you've made the effort to wrap it,
you'd be
> using DynaBean APIs from now forward in any applications that actually use
> these beans.  If you tie yourself to explicitly to the WrapDynaBean
(instead of
> the generic DynaBean) contract, doesn't that prevent you from switching
> DynaBean implementations later on if you find something better/faster?
>
> > 3 seems to me to be a symptom of a bigger issue (which has been known
> > for some time). the exception handling in beanutils is painful and
> > confusing to many users. i'd be very reluctant to break backwards
> > compatibility (even for symantics) and i suspect that the proposed
> > patch does. we've talked before about the possibility of factoring out
> > the exception handling and possible it might be better to fix this
> > rather than the symptom.  so maybe a little more talk and thought is
> > needed about this one.
> >
>
> I'm on general principles opposed to breaking backward compatibility on
method
> names -- but I don't have any problem with efficiency improvements, or
> usability improvements (i.e. error messages that point you at what the
real
> issue is).  I haven't had time to look at your patch yet (slightly busy
with
> JavaServer Faces at the moment ;-), but agree with Robert's general point
that
> an overall review of how BeanUtils is put together as a whole is probably
> overdue.  Indeed, that sort of thing would make sense in the context of a
> BeanUtils 2.0 type discussion, perhaps having 2.x releases while we
continue
> bugfixes on the 1.x track and keep compatibility there.
>
> BeanUtils is a very widely used package, so we have to be even more
careful than
> is typical in j-c about compatibility.  But it's also time to do some
> innovation again, and these sorts of discussions might be a good kickoff
for
> that.
>
> > comments welcome
> >
> > - robert
> >
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>



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


Mime
View raw message