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" <wlegge...@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.and...@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:wlegge...@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-unsubscr...@xmlbeans.apache.org >>> For additional commands, e-mail: dev-h...@xmlbeans.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org >> For additional commands, e-mail: dev-h...@xmlbeans.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org > For additional commands, e-mail: dev-h...@xmlbeans.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
