I'm sorry Jean-Baptiste, I don't get your point. To my understanding, 
the current JavaRpc implementation allows to plug any custom policy 
using the RemoteCallUtils customization. You could even work with the 
transient keyword if you like (using reflection), minus the fields 
visibility problem (see below).

The problem with the Java transient keyword is that it is strongly tied 
to the Java serialization (JVM <-> JVM).
Take for example a transient private field. It is correctly handled by 
the JVM Object serialization but you will not get your hands on it 
through reflection in a "standard" way. So unless you declare all your 
fields public, I don't know if it's even possible to leverage the 
transient keyword for achieving what you need from outside the bean 
class, i.e. the JavaRpc library if your fields are private (and that's 
good design to keep the object state private).
That's why I suggested the use of annotations on the getters (that are 
public by design).

Moreover, there are times where Java beans don't have a "classic" state 
with 1 property <-> 1 field. For instance they could declare a single 
Map field to hold their property values and bean property accessors are 
coded against this map.

BTW, Flex <-> Java serialization (using BlaseDS) works like Qooxdoo 
(i.e. based on bean properties), except :
  -> built-in strong class typing when receiving beans on the Flex side
  -> only writable bean properties are passed over the wire.

Best,
Vincent

Jean-Baptiste BRIAUD -- Novlog a écrit :
> 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:
>
>   

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to