incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <the.mindstorm.mailingl...@gmail.com>
Subject Re: JCR Mapping enhancement request(s)
Date Mon, 02 Jan 2006 11:39:43 GMT
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 <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
>> =======================================================
>>
> 
> 
> 
> 
> !DSPAM:43b8f6e0670361126616474!
> 
> 


Mime
View raw message