incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject Re: JCR Mapping enhancement request(s)
Date Mon, 02 Jan 2006 09:47:39 GMT
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 <the.mindstorm.mailinglist@gmail.com> 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
> =======================================================
>

Mime
View raw message