[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    Re: User type static handler
From:       Wesley Leggette <wleggette () cleversafe ! com>
Date:       2009-03-15 5:41:44
Message-ID: C5E1FF48.AAF3%wleggette () cleversafe ! com
[Download RAW message or body]


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" <wleggette@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" <cezar.andrei@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

[prev in list] [next in list] [prev in thread] [next in thread]