I think there is no need to invent something new : transient old Java
keyword is fully appropriate.
If a property is transient, then, no serialization.
The only problem is that transient keyword apply to field while
JavaRPC is based on JavaBean's accessors and not fields.
It is the same foir persistence like JPA (a Java standard) : annotate
the fields or annotate the accessors.
Both are possible, but the consensus and my prefered way is that
annotating fields is better.
If a refactoring had to be thought on JavaRPC it could be to allow,
like JPA, the choice of specifying the property to kept or to exclude
via accessor or via fields annotation.
This would leave the choice.
In fact, my short term goal was to use JavaRPC changing code as less
as possible but that discussion is important and interesting for next
step : time for refactor.
So, feel free to add ideas ...
On Jul 27, 2009, at 21:05 , Vincent Vandenschrick wrote:
> Or simply annotate the getters of the properties you want to remain
> transient with a custom @QxTransient. This annotation must have a
> runtime retention policy so that you can test it using reflection,
> still
> in your custom RemoteCallUtils.filter(Object , Map) method.
>> Hi Jean-Baptiste,
>> Another option might have been to provide your POJO classes with a
>> static method listing all the serializablePropertyNames, e.g. :
>> public static Set<String> getSerializablePropertyNames();
>>
>> Optimally, the method would return a static Set you construct in the
>> static block of the class.
>>
>> Then simply invoke it using reflection in "protected Map
>> filter(Object
>> obj, Map map)" overriden in a custom RemoteCallUtils. This way, you
>> don't have to change your beans accessors and keep them aligned with
>> the Java conventions (i.e. get/setProperty()).
>>
>> Regards,
>> Vincent
>>
>> Jean-Baptiste BRIAUD -- Novlog a écrit :
>>> Hi,
>>>
>>> As I said later on, here is a quick feedback of my use of JavaRPC.
>>> I used the HEAD of SVN contrib.
>>> I have some specific needs : reuse some POJO that I can modify. In
>>> other words, the same POJO class are used not only by JavaRPC but
>>> also by some other things.
>>> Basically, the only problem I was facing was the choice of what
>>> property I wanted to exclude and what properties I wanted serialise
>>> throw JavaRPC.
>>> I would love to do that with annotation or introspection using
>>> transient Java keyword but this would involve too much JavaRPC
>>> refactoring.
>>>
>>> Finally, I managed to stay in the current design : JavaBean
>>> specification using Apache implementation to detect accessors.
>>> To reach my goal I simply added a new convention and a new method
>>> for filtering properties.
>>> Rather than taking any accessors, I take only those who meet the
>>> namming convention.
>>> The convention :
>>> Let's consider a property p.
>>> One "normal" accessor would be getP() and the other would be
>>> setP(P p).
>>> The convention for an accessor to be serialized throw JavaRPC is :
>>> set_ser_P() and get_ser_P(P p)
>>>
>>> So, the filter from Java to RPC is to keep only _ser_ accessors and
>>> then to remove the _ser_ from Apache bean introspection Map so after
>>> the operation all look like normal accessor.
>>> Then, for the other way around, from RPC to Java, all accessors are
>>> rennamed by adding back _ser_ so the corresponding method on the
>>> POJO accessors will be used to set back the values.
>>>
>>> This allow me to use accessors with the JavaBean design starting
>>> from persistent POJO that are stored from fields annotations (not
>>> from accessors).
>>>
>>> The only method I had to add to RemoteCallUtils API is (default
>>> implem do not filter) :
>>> protected String toJavaFilterName(final Object obj, final
>>> String propertyName) {
>>> return propertyName;
>>> }
>>>
>>> That method could be overrriden to filter or change property name.
>>>
>>> If anyone found that usefull, feel free to ask the code.
>>>
>>> I have to continue using it as it is on my projet and later on, I'll
>>> sit down to think about how this could be improved.
>>>
>>> Hope this helps.
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> qooxdoo-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>>
>>
>>
>
>
> --
> Vincent Vandenschrick
> Jspresso Framework
> http://www.jspresso.org
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
