Re: [Simple-support] Creating a "short" serialization

[Ben W. <si...@be...>]

I can't seem to get the Replace method to work.  I've attached a test 
method to demonstrate.  Perhaps you can show me what I'm doing wrong. :-/

The @Replace/@Resolve methods have promise, but I still don't see a way 
for the person serializing to trigger it.  The closest solution would be 
if "someProperty" in your example below were actually a global property 
set/retrieved via a call to a util class.  However, our code is running 
on a server, and it is quite possible that multiple serializations will 
be happening at the same time -- some "primary key only" and some full.

 >public Object myResolveMethod() {
 >   if(someProperty) {
 >      return new SomeOtherObject(myProperty1, myProperty2);
 >   }
 >   return this; // Here I am saying don't read resolve
 >}

I have coded up the tags possibility.  I can submit a patch if you're 
interested. :-)

Ben

Niall Gallagher wrote:
> Hi,
> 
> Forgot to explain the following code snippit. This
> demonstrates how an @Replace method could be used
> instead of a @Resolve. The @Replace is used in
> writing, it is similar to Java object serialization
> writeReplace.
> 
> @Root
> public class SomeObject {
> 
>    @Element(required=false)
>    private String text;
>    
>    @Attribute(required=false)
>    private int version;
> 
>    @Attribute
>    private String key;
> 
>    public SomeObject() {
>       super();
>    }
> 
>    public SomeObject(String key) {
>       this.key = key;
>    }
> 
>    @Validate
>    public void validate() {
>       // do some validation here...
>    }
> 
>    @Replace
>    private Object writeReplace() {
>       return new SomeObject(key); // Here I provide
> the same type with a subset of the properties
>    }
> }
> 
> You could also use the @Persist and @Complete, the
> method annotated with @Persist is called just before
> serialization of the object, and @Complete is called
> directly after. So you can modify the contents of the
> object before it is serialized and bring the object
> back to a known state when you have finished
> serializing it. So you get a chance to modify the
> object for serialization, there is an example in the
> tutorial.
> 
> Niall
> 
> --- Niall Gallagher <gal...@ya...> wrote:
> 
>> Hi, 
>>
>> This will give you both worlds. Why not do the
>> following:
>>
>> public Object myResolveMethod() {
>>    if(someProperty) {
>>       return new SomeOtherObject(myProperty1,
>> myProperty2);
>>    }
>>    return this; // Here I am saying don't read
>> resolve
>> }
>>
>> When you return "this" from the method annotated
>> with
>> @Resolve annotation you are saying not to resolve to
>> something different. Also, you don't need to return
>> a
>> different type.
>>
>>
>> @Root
>> public class SomeObject {
>>
>>    @Element(required=false)
>>    private String text;
>>    
>>    @Attribute(required=false)
>>    private int version;
>>
>>    @Attribute
>>    private String key;
>>
>>    public SomeObject() {
>>       super();
>>    }
>>
>>    public SomeObject(String key) {
>>       this.key = key;
>>    }
>>
>>    @Validate
>>    public void validate() {
>>       // do some validation here...
>>    }
>>
>>    @Replace
>>    private Object writeReplace() {
>>       return new SomeObject(key); // Here I provide
>> the same type with a subset of the properties
>>    }
>> }
>>
>> Hope this helps.
>>
>> Niall
>>
>>
>> --- Ben Wolfe <si...@be...> wrote:
>>
>>> I'm not sure this will work for me.  I want to
>> have
>>> both worlds.  I want 
>>> to be able to serialize our objects to just their
>>> primary keys sometimes 
>>> and at others be able to serialize all
>> @Attributes,
>>> @Elements, etc on 
>>> the object to xml.
>>>
>>> Ben
>>>
>>> Niall Gallagher wrote:
>>>> Hi,
>>>>
>>>> There is a way you could do this, don't know how
>>> well
>>>> it would suit you. But the @Resolve and @Replace
>>>> annotations are used in situations like this.
>>> Anything
>>>> you can do with the readResolve and writeReplace
>>> for
>>>> conventional object serialization can be done
>> with
>>>> these annotations. Here is an example of what
>> you
>>>> might do.
>>>>
>>>>
>>>> @Root
>>>> public class CompleteObject {
>>>>
>>>>    @Attribute
>>>>    private String name;
>>>>
>>>>    @Element
>>>>    private String id;
>>>>
>>>>    @Element
>>>>    private Stirng address;
>>>>
>>>>    public CompleteObject() {
>>>>       super();                     
>>>>    }
>>>>
>>>>    public CompleteObject(String name, String id)
>> {
>>>>       this.name = name;
>>>>       this.id = id;      
>>>>    }
>>>>
>>>>    @Replace
>>>>    private Object getPrimaryKey() {
>>>>       return new PrimaryKey(name, id);
>>>>    }
>>>>
>>>>    @Root
>>>>    private static class PrimaryKey {
>>>>
>>>>       @Attribute
>>>>       private String name;
>>>>
>>>>       @Element
>>>>       private String id;
>>>>
>>>>       public PrimaryKey() {
>>>>          super();
>>>>       }
>>>>
>>>>       public PrimaryKey(String name, String id)
>> {
>>>>          this.name = name;
>>>>          this.id = id;
>>>>       }
>>>>
>>>>       @Resolve
>>>>       private Object getCompleteObject() {
>>>>          return new CompleteObject(name, id);   
>>  
>>>    
>>>>     
>>>>       }
>>>>    }
>>>> }
>>>>
>>>> If you pair this with a custom Strategy
>>> implementation
>>>> then you can ensure the class="" attributes can
>> be
>>>> replaced with other tokens to indicate what
>>> objects to
>>>> use. This above example is obviously not very
>>> useful,
>>>> but when used properly @Replace and @Resolve can
>>> be
>>>> quite powerful.
>>>>
>>>> Niall
>>>>
>>>> --- Ben Wolfe <si...@be...> wrote:
>>>>
>>>>> We have several places in our code where we
>> could
>>>>> benefit from a shorter 
>>>>> serialization.  We don't need to serialize the
>>>>> entire object, just the 
>>>>> primary keys of the object.
>>>>>
>>>>> I haven't been able to find a way to do this
>> yet.
>>>>> Did I miss something? 
>>>>> Is there a way to do it currently?
>>>>>
>>>>> My thoughts on how to implement it:
>>>>>
>>>>> The primary key attributes/elements would need
>> to
>>> be
>>>>> annotated.  The 
>>>>> most general way to do it would be to add a
>>> String
>>>>> "tag" option to the 
>>>>> "Attribute" and "Element" annotations.  The tag
>>>>> would be a string that 
>>>>> groups certain attributes together and can be
>>> used
>>>>> later.
>>>>> I don't know why it would be necessary right
>> now,
>>>>> but we could have any 
>>>>> number of "sets of serializations" with any
>> named
>>>>> tag we want: A "Short" 
>>>>> one that would (de)derialize to just the
>> primary
>>>>> keys, a "medium" one 
>>>>> that would (de)serialize to only certain
>>> attributes,
> === message truncated ===
> 
> 
> 
>       ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page. 
> http://www.yahoo.com/r/hs