Different Calendar-Serialization in one class / Control transform on element-level

[patb]

Hello,

is there any way I can control the deserialization of a
GregorianCalendar on Element-level?

What I need is to produce XML data with different time-format like
this:

------------
<example>
  <soapTime>2009-09-25T14:00:00.000Z</soapTime>
  <date>2009-09-25</date>
</example>
------------

I know I can use my own Matcher and Transform implementations, but
this works, as long as I know, only on class-level and I can't
distinguish different elements (in my example "soapTime" and "date",
which are all GregorianCalendar instances in the class).

Do you have any idea how to do this?

Very nice would be an annotation like this:

  @Temporal(class=java.util.GregorianCalendar, readPattern="yyy-MM-dd" writePattern="yyy-MM-dd")

This way one has easier control over the serialization process (the
patterns are used together with the SimpleDateFormat class) - just an
idea.


Do you know another way to achieve such different serializtions in
one class?


Thanks a lot for your help


Best regards,
Timo Rumland


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Simple-support mailing list
Simple-support@...
https://lists.sourceforge.net/lists/listinfo/simple-support

[niall.gallagher]

Hi,

You could do this.

public class MyClass{

   private GregorianCalendar soapTime;
   private GregirianCalendar date;

   @Element
   public void setSoapTime(String text) {
      soapTime= MyDateUtil.getCalendar(text)
   }
 
   @Element
   public String getSoapTime() {
      return MyDateUtil.getText(calendar);
   }

   @Element
   public void setDate(String text) {
      date = MyDateUtil.getCalendar(text);
   }

   @Element
   public String getDate() {
      return MyDateUtil.getText(calendar);
   }
}

Alternatively you could just implement a commit method with the @Commit annotation to populate the object.

Niall


Niall Gallagher
RBS Global Banking & Markets
Office: [phone]  

-----Original Message-----
From: Timo Rumland [mailto:cr@...]
Sent: 25 September 2009 15:56
To: simple-support@...
Subject: [Simple-support] Different Calendar-Serialization in one class / Control transform on element-level

Hello,

is there any way I can control the deserialization of a GregorianCalendar on Element-level?

What I need is to produce XML data with different time-format like
this:

------------
<example>
  <soapTime>2009-09-25T14:00:00.000Z</soapTime>
  <date>2009-09-25</date>
</example>
------------

I know I can use my own Matcher and Transform implementations, but this works, as long as I know, only on class-level and I can't distinguish different elements (in my example "soapTime" and "date", which are all GregorianCalendar instances in the class).

Do you have any idea how to do this?

Very nice would be an annotation like this:

  @Temporal(class=java.util.GregorianCalendar, readPattern="yyy-MM-dd" writePattern="yyy-MM-dd")

This way one has easier control over the serialization process (the patterns are used together with the SimpleDateFormat class) - just an idea.


Do you know another way to achieve such different serializtions in one class?


Thanks a lot for your help


Best regards,
Timo Rumland


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________
Simple-support mailing list
Simple-support@...
https://lists.sourceforge.net/lists/listinfo/simple-support

***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorised and regulated by the Financial Services Authority.
 
This e-mail message is confidential and for use by the
addressee only. If the message is received by anyone other
than the addressee, please return the message to the sender
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The
Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.

Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this
message and any attachments will not adversely affect its
systems or data. No responsibility is accepted by The
Royal Bank of Scotland plc in this regard and the recipient should carry
out such virus and other checks as it considers appropriate.

Visit our website at www.rbs.com

***********************************************************************************


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Simple-support mailing list
Simple-support@...
https://lists.sourceforge.net/lists/listinfo/simple-support

[patb]

Hello,


> Hi,
> You could do this.

> public class MyClass{
>
> [...]
>
>    @Element
>    public String getSoapTime() {
>       return MyDateUtil.getText(calendar);
>    }

> Alternatively you could just implement a commit method with the
> @Commit annotation to populate the object.

This has the disadvantage, that I have a String-typed time property
in my class. Not a big deal, but when I work with that domain object,
it is not nice to handle the strings all the time. I know I could
include setters and getters for the real Calendar object, but well...


It would just be nice, if the Matcher.match( Class type ) method could
be extended with a Field (java.lang.reflect.Field) argument. That way,
the matcher can do it's decision based not only on the "Class type",
but also on the Field, it is currently looking at.

With such a Field argument, I could write a Matcher that, for example,
retrieves the Field name or a Field annotation to have more
information to decide which Transform to return (I could even
parameterize such a Field annotation with a custom Transform class,
which would be used).

An example class may look like this:

------------
@Root
public class Example {
  @Element
  @Transform(type=MyCustomCalendarTransform.class)
  private Calendar myTime;
}
------------

(Of course this can also be used for other types than Calendar)


I think this is one way "to do it right", without any workarounds
(like a helper-property of type String, for example).


Do you think it is very hard to extend the Matcher's method so it's
signature is "Matcher.match( Class type, Field field )"?



Thanks a lot for your ideas


Best regards,
Timo Rumland


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Simple-support mailing list
Simple-support@...
https://lists.sourceforge.net/lists/listinfo/simple-support

[niall.gallagher]

Hi,

Ya, a change like this could work nicely. Ill look in to making such a change.

Niall


Niall Gallagher
RBS Global Banking & Markets
Office: [phone]  

-----Original Message-----
From: Timo Rumland [mailto:cr@...]
Sent: 26 September 2009 07:29
To: simple-support@...
Subject: Re: [Simple-support] Different Calendar-Serialization in one class / Control transform on element-level

Hello,


> Hi,
> You could do this.

> public class MyClass{
>
> [...]
>
>    @Element
>    public String getSoapTime() {
>       return MyDateUtil.getText(calendar);
>    }

> Alternatively you could just implement a commit method with the
> @Commit annotation to populate the object.

This has the disadvantage, that I have a String-typed time property in my class. Not a big deal, but when I work with that domain object, it is not nice to handle the strings all the time. I know I could include setters and getters for the real Calendar object, but well...


It would just be nice, if the Matcher.match( Class type ) method could be extended with a Field (java.lang.reflect.Field) argument. That way, the matcher can do it's decision based not only on the "Class type", but also on the Field, it is currently looking at.

With such a Field argument, I could write a Matcher that, for example, retrieves the Field name or a Field annotation to have more information to decide which Transform to return (I could even parameterize such a Field annotation with a custom Transform class, which would be used).

An example class may look like this:

------------
@Root
public class Example {
  @Element
  @Transform(type=MyCustomCalendarTransform.class)
  private Calendar myTime;
}
------------

(Of course this can also be used for other types than Calendar)


I think this is one way "to do it right", without any workarounds (like a helper-property of type String, for example).


Do you think it is very hard to extend the Matcher's method so it's signature is "Matcher.match( Class type, Field field )"?



Thanks a lot for your ideas


Best regards,
Timo Rumland


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________
Simple-support mailing list
Simple-support@...
https://lists.sourceforge.net/lists/listinfo/simple-support

***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorised and regulated by the Financial Services Authority.
 
This e-mail message is confidential and for use by the
addressee only. If the message is received by anyone other
than the addressee, please return the message to the sender
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The
Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.

Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this
message and any attachments will not adversely affect its
systems or data. No responsibility is accepted by The
Royal Bank of Scotland plc in this regard and the recipient should carry
out such virus and other checks as it considers appropriate.

Visit our website at www.rbs.com

***********************************************************************************


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Simple-support mailing list
Simple-support@...
https://lists.sourceforge.net/lists/listinfo/simple-support

[patb]

Hello Niall,

> Hi,
> Ya, a change like this could work nicely. Ill look in to making such
> a change.

this is great news, one of the best supported java frameworks and
responsive mailinglist I know, thanks a lot.

Can you tell a rough time frame for this new feature?


Maybe another improvement to think of is another Annotation
"@Elements", which can be places at the class level, for example:

-----------------
@Root
@Elements( required = false )
public class Example {
    // ...
}
-----------------

This would tell the framework to serialize all fields/class attributes
as if I had placed the "@Element" at each of them. Like a "default
behavior" so I don't have to clutter my code with all those @Element
annotations (maybe this can be just a paramter of the @Root annotation
also). Then you could use the @Transient annotation to select fields
not to serialize.

Just an idea :)


Keep up the good work!



Best regards,
Timo Rumland




------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Simple-support mailing list
Simple-support@...
https://lists.sourceforge.net/lists/listinfo/simple-support

[jpkutner]

Timo,

Your suggestion is similar to a patch I submitted a while back.  I
created an @AccessorType annotation that works as you describe - which
also happens to be the way @XmlAccessorType works in JAXB.  Here's the
link to my post and the patch to make it happen:

http://sourceforge.net/mailarchive/forum.php?thread_name=ece8bb080908131208i699dc568h6cbbbab5a9edca94%40mail.gmail.com&forum_name=simple-support

or here: http://is.gd/3LmBx

Any estimate on when/if this will make it into the trunk?

Thanks,

Joe

On Mon, Sep 28, 2009 at 4:11 PM, Timo Rumland <cr@...> wrote:

> Hello Niall,
>
>> Hi,
>> Ya, a change like this could work nicely. Ill look in to making such
>> a change.
>
> this is great news, one of the best supported java frameworks and
> responsive mailinglist I know, thanks a lot.
>
> Can you tell a rough time frame for this new feature?
>
>
> Maybe another improvement to think of is another Annotation
> "@Elements", which can be places at the class level, for example:
>
> -----------------
> @Root
> @Elements( required = false )
> public class Example {
>    // ...
> }
> -----------------
>
> This would tell the framework to serialize all fields/class attributes
> as if I had placed the "@Element" at each of them. Like a "default
> behavior" so I don't have to clutter my code with all those @Element
> annotations (maybe this can be just a paramter of the @Root annotation
> also). Then you could use the @Transient annotation to select fields
> not to serialize.
>
> Just an idea :)
>
>
> Keep up the good work!
>
>
>
> Best regards,
> Timo Rumland
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Simple-support mailing list
> Simple-support@...
> https://lists.sourceforge.net/lists/listinfo/simple-support
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Simple-support mailing list
Simple-support@...
https://lists.sourceforge.net/lists/listinfo/simple-support

[niall.gallagher]

Hi,

Yes, I will add this in the next major release.

Thanks,
Niall


Niall Gallagher
RBS Global Banking & Markets
Office: [phone]  

-----Original Message-----
From: Joe Kutner [mailto:jpkutner@...]
Sent: 28 September 2009 23:37
To: Timo Rumland
Cc: simple-support@...
Subject: Re: [Simple-support] Different Calendar-Serialization in one class / Control transform on element-level

Timo,

Your suggestion is similar to a patch I submitted a while back.  I created an @AccessorType annotation that works as you describe - which also happens to be the way @XmlAccessorType works in JAXB.  Here's the link to my post and the patch to make it happen:

http://sourceforge.net/mailarchive/forum.php?thread_name=ece8bb080908131208i699dc568h6cbbbab5a9edca94%40mail.gmail.com&forum_name=simple-support

or here: http://is.gd/3LmBx

Any estimate on when/if this will make it into the trunk?

Thanks,

Joe

On Mon, Sep 28, 2009 at 4:11 PM, Timo Rumland <cr@...> wrote:

> Hello Niall,
>
>> Hi,
>> Ya, a change like this could work nicely. Ill look in to making such
>> a change.
>
> this is great news, one of the best supported java frameworks and
> responsive mailinglist I know, thanks a lot.
>
> Can you tell a rough time frame for this new feature?
>
>
> Maybe another improvement to think of is another Annotation
> "@Elements", which can be places at the class level, for example:
>
> -----------------
> @Root
> @Elements( required = false )
> public class Example {
>    // ...
> }
> -----------------
>
> This would tell the framework to serialize all fields/class attributes
> as if I had placed the "@Element" at each of them. Like a "default
> behavior" so I don't have to clutter my code with all those @Element
> annotations (maybe this can be just a paramter of the @Root annotation
> also). Then you could use the @Transient annotation to select fields
> not to serialize.
>
> Just an idea :)
>
>
> Keep up the good work!
>
>
>
> Best regards,
> Timo Rumland
>
>
>
>
> ----------------------------------------------------------------------
> -------- Come build with us! The BlackBerry® Developer Conference
> in SF, CA is the only developer event you need to attend this year.
> Jumpstart your developing skills, take BlackBerry mobile applications
> to market and stay ahead of the curve. Join us from November 9-12,
> 2009. Register now! http://p.sf.net/sfu/devconf 
> _______________________________________________
> Simple-support mailing list
> Simple-support@...
> https://lists.sourceforge.net/lists/listinfo/simple-support
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________
Simple-support mailing list
Simple-support@...
https://lists.sourceforge.net/lists/listinfo/simple-support

***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorised and regulated by the Financial Services Authority.
 
This e-mail message is confidential and for use by the
addressee only. If the message is received by anyone other
than the addressee, please return the message to the sender
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The
Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.

Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this
message and any attachments will not adversely affect its
systems or data. No responsibility is accepted by The
Royal Bank of Scotland plc in this regard and the recipient should carry
out such virus and other checks as it considers appropriate.

Visit our website at www.rbs.com

***********************************************************************************


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Simple-support mailing list
Simple-support@...
https://lists.sourceforge.net/lists/listinfo/simple-support