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
