[
http://issues.apache.org/jira/browse/BEANUTILS-185?page=comments#action_12415706
]
Niall Pemberton commented on BEANUTILS-185:
-------------------------------------------
<snip>
* 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() method)
</snip>
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.
<snip>
* 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.
</snip>
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.
<snip>
* 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="#{dynabean.property}"/>, which will read and WRITE on the
dynabean.
</snip>
This is easy to do either way - mutable or not.
<snip>
* 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.
</snip>
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: http://issues.apache.org/jira/browse/BEANUTILS-185
> Project: Commons BeanUtils
> Type: Improvement
> Environment: Operating System: other
> Platform: Other
> Reporter: Gabriel Belingueres
> Priority: Minor
> Attachments: AbstractRowSetDynaClass.java, BasicDirectAccessDynaBean.java,
> BasicDirectAccessDynaBeanTestCase.java, BasicIndirectAccessDynaBean.java,
> DirectAccessDynaBean.java, DirectRowSetDynaClass.java,
> IndirectAccessDynaBean.java, IndirectRowSetDynaClass.java, 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:
> http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=114669123403779&w=2
> I attach the diff file that comprises changes to the RowSetDynaClass.java
> 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
> [EMAIL PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
