commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton (JIRA)" <>
Subject [jira] Commented: (BEANUTILS-185) [beanutils] Try to align BeanUtils with JSTL standard tags
Date Sat, 10 Jun 2006 20:27:30 GMT
    [ ] 

Niall Pemberton commented on BEANUTILS-185:

* I introduced the AbstractRowSetDynaClass class for two reasons I can remember of now: 
a) To tell with the code by itself that there is a Factory Method createDynaBean() and it
is OK to create your own type of RowSetDynaClass which create the kind of row beans you want.

b) The introduction of the AbstractRowSetDynaClass class made it really easy to introduce
both the DirectRowSetDynaClass and IndirectRowSetDynaClass (we only implement the createDynaBean()

OK but I don't see anything different here that changes my mind about what I said about the
existing createDynaBean() in RowSetDynaClass - your new direct/indirect DynaClass implementations
could extend RowSetDynaClass and override that method.

* If I understood it well, I think newInstance() would not be an adequate method to use in
this situation. From the DynaClass javadoc: "A DynaClass is a simulation of the functionality
of java.lang.Class for classes implementing the DynaBean interface". 
If in a regular Java program I call newInstance() on the java.util.ArrayList class, I would
not expect to be returned a new Object instance because it is the type of objects an ArrayList
can hold, but I would expect to be returned an instance of a new ArrayList. 
With RowSetDynaClass I think it happens the same: calling newInstance() one would expect I
get returned a new RowSetDynaBean (which it is a concept that doesn't exist!), not a BasicDynaBean
instance (which is the type of the elements in the RowSet. I think that it is why when called
it throws an UnsupportedOperationException. 

RowSetDynaClass is still the DynaClass (i.e. property meta data) for the individual "row"
DynaBeans (in this case BasicDynaBean) and so I would disagree with you - newInstance() is
exactly what should be called. Just because it bizarely creates a List of those DynaBeans
as well doesn't change that.

* I agree that this is dangerous. I wanted to use JSTL tags like <c:out value="${dynabean.firstname}"/>
with my dynabeans, so the combination of DynaBean and Map seemed a good idea. The BasicDirectAccessDynaBean
implementation I provided treats the dynabean (when accessed from a Map method) as immutable.

In the one hand, read access was the only thing I needed since I use JSTL with a model 2 mvc
framework (so no writing is performed in the JSP pages), and in the other hand, I wrapped
the map in a Collections.unmodifiableMap to protect the dynabean integrity from writing. 
I tend to agree that this super interface may be opening the door for bugs. However, I think
that before dropping it we could consult with a JSF implementer to see if it would simplify
the implementation of expressions like <h:inputText value="#{}"/>,
which will read and WRITE on the dynabean. 

This is easy to do either way - mutable or not.

* This can be a good idea, however if you wrap a DynaBean with a Map interface, then it is
no longer a DynaBean. Don't know if this loss of functionality can be counter productive or
not, but would cover the requirement of being JSTL friendly. 
Also, this will require to either change the RowSetDynaClass.copy() implementation to wrap
the dynabean with an optional Map, or (easier I think) add a getRowsAsMap() method which would
create a list of Map-wrapped dynabeans. 

Yes this can be done - I've created an implementation which I will attache.

Also I'm happy to add getMap() method to BasicDynaBean which returns a Map decorator - which
would provide the "indirect" access method of your requirement.

> [beanutils] Try to align BeanUtils with JSTL standard tags
> ----------------------------------------------------------
>          Key: BEANUTILS-185
>          URL:
>      Project: Commons BeanUtils
>         Type: Improvement

>  Environment: Operating System: other
> Platform: Other
>     Reporter: Gabriel Belingueres
>     Priority: Minor
>  Attachments:,,,,,,,, beanutil-diff.txt
> Hi,
> I've done some modifications to the beanutils package to better support the use 
> of DynaBeans with the JSTL tags. Some of the changes are discussed in this 
> thread of the commons-user mailing list:
> I attach the diff file that comprises changes to the file 
> and build.xml file (since I added a TestCase.) Note: Please try to filter 
> carefully the diffs in the build.xml file since they include some local 
> settings I have for compilation on my machine. :-(
> Together with the diff file, I attach the new java files added to the package.
> Regards,
> Gabriel Belingueres

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

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

View raw message