You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by Wesley Leggette <wl...@cleversafe.com> on 2009/03/08 20:35:04 UTC
User type static handler
Hello,
I often run into the situation where I want to use a custom (non-built in)
simple type in an XML document that would be well translated to a Java
class. A UUID is a good example:
<xs:simpleType name="uuid">
<xs:restriction base="xs:string">
<xs:pattern
value="[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}"/>
</xs:restriction>
</xs:simpleType>
Here, xs:string is the base class, obviously. What would be nice is to
indicate in the xsdconfig a handler to convert the base class into a UUID
and have any xmlbeans generated interfaces return and set a UUID in the
convenience getters and setters. The xget and xset would obviously remain
the same.
A simple encoder/decoder for the UUID example would look like this:
String encodeUuid(XmlObject xmlObj, UUID obj)
UUID decodeUuid(XmlObject xmlObj, String str)
Where in general the signature would have to be:
SomeXmlSimpleType encodeUserTypeName(XmlObject xmlObj, JavaUserType obj)
JavaUserType decodeUserTypeName(XmlObject xmlObj, SomeXmlSimpleType type)
Question: In the signature should it be String (the java convenience type)
or the XML type (e.g., XmlString)? Or perhaps the actual derived simple type
(the type returned by the matching xget)?
The xsdconfig would generally look like the following:
<xb:usertype name="uuid" javaname="java.util.UUID">
<xb:staticHandler>com.example.UUIDType</xb:staticHandler>
</xb:usertype>
So, operationally, that would be my proposal. Obviously I am looking for any
input on that aspect.
Additionally, I would like any advice on the implementation approach I
should take.
As for the actual generated code, the biggest problem I have with the
extensions interface stuff is that it statically compiles in references to
the static handlers, which is a pain for circular dependencies. I'm planning
on using reflection to get a handle on the static handler, and wonder if
there are any major objections here. Obviously it's less efficient at
runtime and can result in runtime linking problems, but for my use this is
not going to be a problem. The only reason I mention it is to question
whether it's so objectionable to the general population that I need to add
some sort of scomp flag that allows use of reflection to be optional.
Some other thoughts:
Why can't I just use extensions interface? Extensions interface is to much
of a kludge. It acts on elements, when I just need to extend the type
system.
I was originally thinking of attaching this sort of functionality to
individual elements or attributes, but I changed my mind and decided that
this is really a type system thing.
Thanks for any input.
Wesley Leggette
Cleversafe, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
Re: User type static handler
Posted by Wesley Leggette <wl...@cleversafe.com>.
I've added the proposal to the wiki at:
http://wiki.apache.org/xmlbeans/UserTypes
I was not sure where to link this from, so I didn't add any links to it yet.
Wesley
On 3/10/09 17:34, "Wesley Leggette" <wl...@cleversafe.com> wrote:
>
> Will add the proposal.
>
> Also, I am fairly close to an initial proposed implementation. I am aware
> that I probably went about it in a bad way, but I figured it's best to make
> a false start and get direct feedback!
>
> As for the performance thing, the approach I am using now has the generated
> code use the Java reflection API to find the static handlers. This is
> obviously horrible for performance, but it so greatly eases compile system
> setup that it is personally a requirement for me for now. But I would again
> stress that I am fully aware that reflection is not a performant solution
> and that I will likely need to add in an option to have the generated code
> directly link with the static handlers.
>
> Thanks for your advice so far,
>
> Wesley
>
>
> On 3/10/09 15:56, "Cezar Andrei" <ce...@oracle.com> wrote:
>
>> Wesley,
>>
>> In my opinion, this is a good idea; though not extremely hard it will not be
>> very easy for you to add it. You'll need to modify the schema of the config
>> file, the code that handles it, the runtime code maybe even the generation
>> code. The best way to start is to look at how XmlStringRestriction and its
>> superclasses are defined and used.
>>
>> The Extension feature is used to add code to the impl classes XMLBeans
>> generates, if that is what you're looking for, even if it's a little
>> complicated to use (performance reasons for this approach) it's much easier
>> than the change you're proposing. But it seems that what you want is to keep
>> the simple data into your own class.
>>
>> Would you mind adding an official proposal on the wiki
>> http://wiki.apache.org/xmlbeans/ that would include a detailed example on the
>> lines of what you have in your email?
>>
>> Cezar
>>
>>> -----Original Message-----
>>> From: Wesley Leggette [mailto:wleggette@cleversafe.com]
>>> Sent: Sunday, March 08, 2009 2:35 PM
>>> To: dev@xmlbeans.apache.org
>>> Subject: User type static handler
>>>
>>> Hello,
>>>
>>> I often run into the situation where I want to use a custom (non-built in)
>>> simple type in an XML document that would be well translated to a Java
>>> class. A UUID is a good example:
>>>
>>> <xs:simpleType name="uuid">
>>>
>>> <xs:restriction base="xs:string">
>>>
>>> <xs:pattern
>>> value="[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}"/>
>>>
>>> </xs:restriction>
>>>
>>> </xs:simpleType>
>>>
>>> Here, xs:string is the base class, obviously. What would be nice is to
>>> indicate in the xsdconfig a handler to convert the base class into a UUID
>>> and have any xmlbeans generated interfaces return and set a UUID in the
>>> convenience getters and setters. The xget and xset would obviously remain
>>> the same.
>>>
>>>
>>>
>>> A simple encoder/decoder for the UUID example would look like this:
>>>
>>> String encodeUuid(XmlObject xmlObj, UUID obj)
>>>
>>> UUID decodeUuid(XmlObject xmlObj, String str)
>>>
>>> Where in general the signature would have to be:
>>>
>>> SomeXmlSimpleType encodeUserTypeName(XmlObject xmlObj, JavaUserType obj)
>>>
>>> JavaUserType decodeUserTypeName(XmlObject xmlObj, SomeXmlSimpleType
>>> type)
>>>
>>>
>>> Question: In the signature should it be String (the java convenience type)
>>> or the XML type (e.g., XmlString)? Or perhaps the actual derived simple
>>> type
>>> (the type returned by the matching xget)?
>>>
>>>
>>> The xsdconfig would generally look like the following:
>>>
>>>
>>> <xb:usertype name="uuid" javaname="java.util.UUID">
>>> <xb:staticHandler>com.example.UUIDType</xb:staticHandler>
>>> </xb:usertype>
>>>
>>>
>>> So, operationally, that would be my proposal. Obviously I am looking for
>>> any
>>> input on that aspect.
>>>
>>> Additionally, I would like any advice on the implementation approach I
>>> should take.
>>>
>>> As for the actual generated code, the biggest problem I have with the
>>> extensions interface stuff is that it statically compiles in references to
>>> the static handlers, which is a pain for circular dependencies. I'm
>>> planning
>>> on using reflection to get a handle on the static handler, and wonder if
>>> there are any major objections here. Obviously it's less efficient at
>>> runtime and can result in runtime linking problems, but for my use this is
>>> not going to be a problem. The only reason I mention it is to question
>>> whether it's so objectionable to the general population that I need to add
>>> some sort of scomp flag that allows use of reflection to be optional.
>>>
>>>
>>> Some other thoughts:
>>>
>>> Why can't I just use extensions interface? Extensions interface is to much
>>> of a kludge. It acts on elements, when I just need to extend the type
>>> system.
>>>
>>> I was originally thinking of attaching this sort of functionality to
>>> individual elements or attributes, but I changed my mind and decided that
>>> this is really a type system thing.
>>>
>>>
>>> Thanks for any input.
>>>
>>> Wesley Leggette
>>> Cleversafe, Inc.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
>>> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
>> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
Re: User type static handler
Posted by Wesley Leggette <wl...@cleversafe.com>.
Will add the proposal.
Also, I am fairly close to an initial proposed implementation. I am aware
that I probably went about it in a bad way, but I figured it's best to make
a false start and get direct feedback!
As for the performance thing, the approach I am using now has the generated
code use the Java reflection API to find the static handlers. This is
obviously horrible for performance, but it so greatly eases compile system
setup that it is personally a requirement for me for now. But I would again
stress that I am fully aware that reflection is not a performant solution
and that I will likely need to add in an option to have the generated code
directly link with the static handlers.
Thanks for your advice so far,
Wesley
On 3/10/09 15:56, "Cezar Andrei" <ce...@oracle.com> wrote:
> Wesley,
>
> In my opinion, this is a good idea; though not extremely hard it will not be
> very easy for you to add it. You'll need to modify the schema of the config
> file, the code that handles it, the runtime code maybe even the generation
> code. The best way to start is to look at how XmlStringRestriction and its
> superclasses are defined and used.
>
> The Extension feature is used to add code to the impl classes XMLBeans
> generates, if that is what you're looking for, even if it's a little
> complicated to use (performance reasons for this approach) it's much easier
> than the change you're proposing. But it seems that what you want is to keep
> the simple data into your own class.
>
> Would you mind adding an official proposal on the wiki
> http://wiki.apache.org/xmlbeans/ that would include a detailed example on the
> lines of what you have in your email?
>
> Cezar
>
>> -----Original Message-----
>> From: Wesley Leggette [mailto:wleggette@cleversafe.com]
>> Sent: Sunday, March 08, 2009 2:35 PM
>> To: dev@xmlbeans.apache.org
>> Subject: User type static handler
>>
>> Hello,
>>
>> I often run into the situation where I want to use a custom (non-built in)
>> simple type in an XML document that would be well translated to a Java
>> class. A UUID is a good example:
>>
>> <xs:simpleType name="uuid">
>>
>> <xs:restriction base="xs:string">
>>
>> <xs:pattern
>> value="[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}"/>
>>
>> </xs:restriction>
>>
>> </xs:simpleType>
>>
>> Here, xs:string is the base class, obviously. What would be nice is to
>> indicate in the xsdconfig a handler to convert the base class into a UUID
>> and have any xmlbeans generated interfaces return and set a UUID in the
>> convenience getters and setters. The xget and xset would obviously remain
>> the same.
>>
>>
>>
>> A simple encoder/decoder for the UUID example would look like this:
>>
>> String encodeUuid(XmlObject xmlObj, UUID obj)
>>
>> UUID decodeUuid(XmlObject xmlObj, String str)
>>
>> Where in general the signature would have to be:
>>
>> SomeXmlSimpleType encodeUserTypeName(XmlObject xmlObj, JavaUserType obj)
>>
>> JavaUserType decodeUserTypeName(XmlObject xmlObj, SomeXmlSimpleType
>> type)
>>
>>
>> Question: In the signature should it be String (the java convenience type)
>> or the XML type (e.g., XmlString)? Or perhaps the actual derived simple
>> type
>> (the type returned by the matching xget)?
>>
>>
>> The xsdconfig would generally look like the following:
>>
>>
>> <xb:usertype name="uuid" javaname="java.util.UUID">
>> <xb:staticHandler>com.example.UUIDType</xb:staticHandler>
>> </xb:usertype>
>>
>>
>> So, operationally, that would be my proposal. Obviously I am looking for
>> any
>> input on that aspect.
>>
>> Additionally, I would like any advice on the implementation approach I
>> should take.
>>
>> As for the actual generated code, the biggest problem I have with the
>> extensions interface stuff is that it statically compiles in references to
>> the static handlers, which is a pain for circular dependencies. I'm
>> planning
>> on using reflection to get a handle on the static handler, and wonder if
>> there are any major objections here. Obviously it's less efficient at
>> runtime and can result in runtime linking problems, but for my use this is
>> not going to be a problem. The only reason I mention it is to question
>> whether it's so objectionable to the general population that I need to add
>> some sort of scomp flag that allows use of reflection to be optional.
>>
>>
>> Some other thoughts:
>>
>> Why can't I just use extensions interface? Extensions interface is to much
>> of a kludge. It acts on elements, when I just need to extend the type
>> system.
>>
>> I was originally thinking of attaching this sort of functionality to
>> individual elements or attributes, but I changed my mind and decided that
>> this is really a type system thing.
>>
>>
>> Thanks for any input.
>>
>> Wesley Leggette
>> Cleversafe, Inc.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
>> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
RE: User type static handler
Posted by Cezar Andrei <ce...@oracle.com>.
Wesley,
In my opinion, this is a good idea; though not extremely hard it will not be very easy for you to add it. You'll need to modify the schema of the config file, the code that handles it, the runtime code maybe even the generation code. The best way to start is to look at how XmlStringRestriction and its superclasses are defined and used.
The Extension feature is used to add code to the impl classes XMLBeans generates, if that is what you're looking for, even if it's a little complicated to use (performance reasons for this approach) it's much easier than the change you're proposing. But it seems that what you want is to keep the simple data into your own class.
Would you mind adding an official proposal on the wiki http://wiki.apache.org/xmlbeans/ that would include a detailed example on the lines of what you have in your email?
Cezar
> -----Original Message-----
> From: Wesley Leggette [mailto:wleggette@cleversafe.com]
> Sent: Sunday, March 08, 2009 2:35 PM
> To: dev@xmlbeans.apache.org
> Subject: User type static handler
>
> Hello,
>
> I often run into the situation where I want to use a custom (non-built in)
> simple type in an XML document that would be well translated to a Java
> class. A UUID is a good example:
>
> <xs:simpleType name="uuid">
>
> <xs:restriction base="xs:string">
>
> <xs:pattern
> value="[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}"/>
>
> </xs:restriction>
>
> </xs:simpleType>
>
> Here, xs:string is the base class, obviously. What would be nice is to
> indicate in the xsdconfig a handler to convert the base class into a UUID
> and have any xmlbeans generated interfaces return and set a UUID in the
> convenience getters and setters. The xget and xset would obviously remain
> the same.
>
>
>
> A simple encoder/decoder for the UUID example would look like this:
>
> String encodeUuid(XmlObject xmlObj, UUID obj)
>
> UUID decodeUuid(XmlObject xmlObj, String str)
>
> Where in general the signature would have to be:
>
> SomeXmlSimpleType encodeUserTypeName(XmlObject xmlObj, JavaUserType obj)
>
> JavaUserType decodeUserTypeName(XmlObject xmlObj, SomeXmlSimpleType
> type)
>
>
> Question: In the signature should it be String (the java convenience type)
> or the XML type (e.g., XmlString)? Or perhaps the actual derived simple
> type
> (the type returned by the matching xget)?
>
>
> The xsdconfig would generally look like the following:
>
>
> <xb:usertype name="uuid" javaname="java.util.UUID">
> <xb:staticHandler>com.example.UUIDType</xb:staticHandler>
> </xb:usertype>
>
>
> So, operationally, that would be my proposal. Obviously I am looking for
> any
> input on that aspect.
>
> Additionally, I would like any advice on the implementation approach I
> should take.
>
> As for the actual generated code, the biggest problem I have with the
> extensions interface stuff is that it statically compiles in references to
> the static handlers, which is a pain for circular dependencies. I'm
> planning
> on using reflection to get a handle on the static handler, and wonder if
> there are any major objections here. Obviously it's less efficient at
> runtime and can result in runtime linking problems, but for my use this is
> not going to be a problem. The only reason I mention it is to question
> whether it's so objectionable to the general population that I need to add
> some sort of scomp flag that allows use of reflection to be optional.
>
>
> Some other thoughts:
>
> Why can't I just use extensions interface? Extensions interface is to much
> of a kludge. It acts on elements, when I just need to extend the type
> system.
>
> I was originally thinking of attaching this sort of functionality to
> individual elements or attributes, but I changed my mind and decided that
> this is really a type system thing.
>
>
> Thanks for any input.
>
> Wesley Leggette
> Cleversafe, Inc.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org