AtomicTypeConvertors JIRA issue: http://issues.apache.org/jira/browse/GRFT-83
Patch provided.
tia,
./alex
--
.w( the_mindstorm )p.
#: Christophe Lombart changed the world a bit at a time by saying on 1/2/2006
11:47 AM :#
Hi Alex,
Happy new year ! It is nice to see you here :-)
Well, I have no special comments to your suggestions. Your proposed
patches will be welcome. Can you add them in the Graffito jira
application ? Concerning your third suggestion : yes there is a plan
to add a cache service in this mapping framework.
Do you plan to use this mapping tools in Magnolia ?
Kind regards,
Christophe
On 1/2/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
Hi!
This is my first mail to this list and I would like to wish everybody here a
Happy New Year!
I have started to try using Graffito JCR Mapping into the project I am working
now. I've been
investigating the code so far and I would like to ask you about the possibility
of adding a few
enhancements.
1/ new attribute in the mapping DTD.
I would like to have an additional fieldType=fully_qualified_class_name in
field-descriptor and also
bean-descriptor. This would bring 2 benefits:
i/ the possibility to generate a source class from the mapping
ii/ the possibility to remove an inspection step (f.e. in ObjectConverterImpl).
If you agree with this I can provide the needed patch quite immediately :-).
2/ AtomicTypeConverters
The atomic type converters are dependent on a ValueFactory which can be
retrieved from the current
Session. I would like to ask if it is possible to add a
setValueFactory(ValueFactory) to the
AtomicTypeConvert interface and make all the default implementors have both a
no-arg constructor and
the current one.
This will allow an easy creation of converters (((AtomicTypeConverter)
converterClass.newInstance()).setValueFactory() instead of the longer version
using the actual
constructor).
Once again if you agree with this change I can provide the needed patch quite
immediately.
3/ Reflective access
Another thing that I am looking for (but not so urgent) would be to optimize
the reflective access,
by caching some of the information (so that the beanutils are not used every
time). Currently the
reflection performance is quite good, and I don't expect to see a big impact on
this, but
considering large sets of objects the impact may be important.
cheers,
./alex
--
.w( the_mindstorm )p.
=======================================================
Me : Alexandru Popescu
Contact : the_mindstorm[at]evolva[dot]ro
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Projects:
TestNG [co-author]: http://testng.org
Magnolia [committer]: http://www.magnolia.info
WebWork [committer]: http://opensymphony.com/webwork
=======================================================
!DSPAM:43b8f6e0670361126616474!
