You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Jens Hübel <jh...@opentext.com> on 2011/11/01 20:42:50 UTC
Client API: Make DateTime in convertProperties more tolerant
Hi Chemistries,
the client API is pretty tolerant against various data types in a property map. For example, byte, int, long etc are all accepted for an Integer property which is a BigInteger in Java.
However for DateTime the converter is very restrictive and just allows GregorianCalendar. Wouldn't it be more consistent and friendlier if we would also allow a java.util.Date and an XmlGregorianCalendar here and take care of the conversion? Furthermore the error message is not very helpful: "Property 'xyz' is a DateTime property!" doesn't tell you anything about the accepted type. "Property xyz is of type x but expected is type y" would be much better.
Is there any reason for this I haven't seen?
It also would be helpful for the client developers guide to provide a code fragment how to set custom properties of the various types. The section "Advanced use of types" only describes how to read them. The fact that the Map must not necessarily be a Map<String, String> as in the various examples, but can also be a Map<String, Object> may not be so obvious for everyone (not a big deal of course).
Jens
RE: Client API: Make DateTime in convertProperties more tolerant
Posted by Jens Hübel <jh...@opentext.com>.
or perhaps make the time zone to use a setting in the OperationContext? Probably overkill ... just thinking loudly.
-----Original Message-----
From: Jens Hübel [mailto:jhuebel@opentext.com]
Sent: Dienstag, 1. November 2011 23:11
To: Florian Müller; dev@chemistry.apache.org
Subject: RE: Client API: Make DateTime in convertProperties more tolerant
I just had a use case where I parse an XML and convert the data to CMIS objects. Of course converting this in my user code is not a big issue, but perhaps this is not such exotic either.
I would assume that most clients want to use their local timezone. I think for other timezones it is okay if the using code has to take for the proper conversion in this case.
I am open to other suggestions as well.
Jens
-----Original Message-----
From: Florian Müller [mailto:florian.mueller@alfresco.com]
Sent: Dienstag, 1. November 2011 22:03
To: dev@chemistry.apache.org
Cc: Jens Hübel
Subject: Re: Client API: Make DateTime in convertProperties more tolerant
Hi Jens,
Supporting XmlGregorianCalendar would not be an issue, but it is not a commonly used data type.
Date objects don't have a timezone. In order to support those we would have to decide with timezone to use. GMT or the local timezone of client would be obvious choices. Any suggestions?
- Florian
On 01/11/2011 12:42, Jens Hübel wrote:
> Hi Chemistries,
>
>
>
> the client API is pretty tolerant against various data types in a property map. For example, byte, int, long etc are all accepted for an Integer property which is a BigInteger in Java.
>
>
>
> However for DateTime the converter is very restrictive and just allows GregorianCalendar. Wouldn't it be more consistent and friendlier if we would also allow a java.util.Date and an XmlGregorianCalendar here and take care of the conversion? Furthermore the error message is not very helpful: "Property 'xyz' is a DateTime property!" doesn't tell you anything about the accepted type. "Property xyz is of type x but expected is type y" would be much better.
>
>
>
> Is there any reason for this I haven't seen?
>
>
>
> It also would be helpful for the client developers guide to provide a code fragment how to set custom properties of the various types. The section "Advanced use of types" only describes how to read them. The fact that the Map must not necessarily be a Map<String, String> as in the various examples, but can also be a Map<String, Object> may not be so obvious for everyone (not a big deal of course).
>
>
>
> Jens
>
>
>
>
RE: Client API: Make DateTime in convertProperties more tolerant
Posted by Jens Hübel <jh...@opentext.com>.
I just had a use case where I parse an XML and convert the data to CMIS objects. Of course converting this in my user code is not a big issue, but perhaps this is not such exotic either.
I would assume that most clients want to use their local timezone. I think for other timezones it is okay if the using code has to take for the proper conversion in this case.
I am open to other suggestions as well.
Jens
-----Original Message-----
From: Florian Müller [mailto:florian.mueller@alfresco.com]
Sent: Dienstag, 1. November 2011 22:03
To: dev@chemistry.apache.org
Cc: Jens Hübel
Subject: Re: Client API: Make DateTime in convertProperties more tolerant
Hi Jens,
Supporting XmlGregorianCalendar would not be an issue, but it is not a commonly used data type.
Date objects don't have a timezone. In order to support those we would have to decide with timezone to use. GMT or the local timezone of client would be obvious choices. Any suggestions?
- Florian
On 01/11/2011 12:42, Jens Hübel wrote:
> Hi Chemistries,
>
>
>
> the client API is pretty tolerant against various data types in a property map. For example, byte, int, long etc are all accepted for an Integer property which is a BigInteger in Java.
>
>
>
> However for DateTime the converter is very restrictive and just allows GregorianCalendar. Wouldn't it be more consistent and friendlier if we would also allow a java.util.Date and an XmlGregorianCalendar here and take care of the conversion? Furthermore the error message is not very helpful: "Property 'xyz' is a DateTime property!" doesn't tell you anything about the accepted type. "Property xyz is of type x but expected is type y" would be much better.
>
>
>
> Is there any reason for this I haven't seen?
>
>
>
> It also would be helpful for the client developers guide to provide a code fragment how to set custom properties of the various types. The section "Advanced use of types" only describes how to read them. The fact that the Map must not necessarily be a Map<String, String> as in the various examples, but can also be a Map<String, Object> may not be so obvious for everyone (not a big deal of course).
>
>
>
> Jens
>
>
>
>
Re: Client API: Make DateTime in convertProperties more tolerant
Posted by Florian Müller <fl...@alfresco.com>.
Hi Jens,
Supporting XmlGregorianCalendar would not be an issue, but it is not a commonly used data type.
Date objects don't have a timezone. In order to support those we would have to decide with timezone to use. GMT or the local timezone of client would be obvious choices. Any suggestions?
- Florian
On 01/11/2011 12:42, Jens Hübel wrote:
> Hi Chemistries,
>
>
>
> the client API is pretty tolerant against various data types in a property map. For example, byte, int, long etc are all accepted for an Integer property which is a BigInteger in Java.
>
>
>
> However for DateTime the converter is very restrictive and just allows GregorianCalendar. Wouldn't it be more consistent and friendlier if we would also allow a java.util.Date and an XmlGregorianCalendar here and take care of the conversion? Furthermore the error message is not very helpful: "Property 'xyz' is a DateTime property!" doesn't tell you anything about the accepted type. "Property xyz is of type x but expected is type y" would be much better.
>
>
>
> Is there any reason for this I haven't seen?
>
>
>
> It also would be helpful for the client developers guide to provide a code fragment how to set custom properties of the various types. The section "Advanced use of types" only describes how to read them. The fact that the Map must not necessarily be a Map<String, String> as in the various examples, but can also be a Map<String, Object> may not be so obvious for everyone (not a big deal of course).
>
>
>
> Jens
>
>
>
>