From: Ryan <ryle...@gmail.com>
To: Dave Kuhlman <dkuhl...@rexx.com>
Sent: Tuesday, April 21, 2009 8:59:01 AM
Subject: Re: generateDS
> Hi Dave,
>
> One feature that I felt was missing from the generated classes was
> validation of the inputs to __init__. The problem I had was that
> if some class expects an int argument and you happen to pass a str
> value (which is perhaps coercable to an int), then when serializing
> to XML, export() will fail very ungracefully due to string
> formatting ("%d" is what fails).
>
> I was OK with this, however, since it can be argued that it's not
> the job of generateDS to validate, as long as the user has the
> necessary type information to implement their own validation
> strategy. So, what I did was use the extra methods feature to add
> a staticmethod wrapper to each class called init() which in
> addition to accepting keyword arguments to be fowarded to
> __init__(), takes a "validator" object. The validator object is
> able to do its work by being passed the following information: the
> name of the object, its value, and its expected type. The expected
> types are quite conveniently stored as _MemberSpec objects in
> _member_data_items for each class.
>
> This strategy worked great for my purposes until I ran into
> elements which contain attributes. I found that for attributes no
> such spec was created by generateDS and so the type information was
> effectively lost. Thus at runtime there was no convenient way to
> do my custom validation/coercion of attribute values without having
> to hardcode the expected types!
Sounds like a useful addition. I'll look into it before too long,
I hope.
And, I'm glad that you found a use for User Methods. That's what
we are talking about, right?
(http://www.rexx.com/~dkuhlman/generateDS.html#user-methods)
That seems like a good use for generateDS.py user methods.
>
> I found that by simply adding a little bit of code to
> generateMemberSpec() I was able to have _MemberSpec objects created
> for attributes:
>
> for attrName, attrDef in element.getAttributeDefs().items():
> item1 = attrName
> item2 = attrDef.getType()
> item3 = 0
> item = " _MemberSpec('%s', '%s', %d)," % (item1, item2, item3,
> )
> add(item)
>
Thanks for this. Give me a bit of time to see how it works a to
test it.
> This seems to work well, and I believe in attrDefs you have even
> already taken care of the possibility for name collisions between
> attribute names and child element names.
>
> I would definitely love to see support for the attribute types in a
> future version of generateDS, though I realize you may want to see
> it implemented differently. The reason would probably be for
> backwards compatibility. People who already have code depending on
> _member_data_items might be inconvenienced if its definition can
> suddenly change. On the other hand, making a separate list for
> member data items can be awkward since now users like myself will
> need to check in *two* places to find the type for a given name.
> Perhaps, a solution in the middle of convience and compat where we
> do actually add attribute values to _member_data_items but instead
> of them being _MemberSpec they are of a different type: _AttrSpec
> (which might even inherit from _MemberSpec). Not really sure how
> you'd like to do this, but I'd love to work with you on this.
>
> As an aside, I wondered if you had yet encountered any other Python
> libraries/scripts capable of doing what generateDS does? I
> personally have not, and although I've been pretty happy with
> generateDS, I am kind of surprised that there's not many others out
> there working on similar things in Python. I have seen things for
> languages like Java, C#, however. For instance, XMLSpy seems to be
> able to generate classes for those languages.
I do not know of another project that does the same thing that
generateDS.py does (generate Python code from XML Schemas).
However, there are several projects that solve a similar problem in
a different way:
- Gnosis/objectify -- I'm not too sure whether this one is still
supported, but it's probably usable all the same. I wrote a
comparison document (comparing Gnosis/objectify and
generateDS.py) a number of years ago (but watch out for my biases:
http://www.rexx.com/~dkuhlman/gnosis_generateds.html
- lxml.objectify -- This one is still supported, and the Web site
says that it is similar to Gnosis/objectify. You can learn
about it here:
http://codespeak.net/lxml/objectify.html
lxml requires libxml, which is an XML library implemented in C.
I've also used XMLBeans with Jython. XMLBeans generates Java code
or a Java jar file containing compiled Java code, and Jython is
happy using that. I believe that the newer version of XMLBeans is
called Java Architecture for XML Binding (JAXB). So, if Jython is
an option for your project, you might want to look at these. You
can find information on both at Wikipedia.org:
- http://en.wikipedia.org/wiki/XMLBeans
- http://en.wikipedia.org/wiki/Java_Architecture_for_XML_Binding
>
> -Ryan
>
> P.S. How did the Chicago trip go? I hope you checked out the Navy
> Pier!
Argh! If we had only had one more day. We could only have so much
fun in one week. There is so much to see in Chicago. We kept
telling ourselves that we had to get to Navy Pier, but ran out of
time. We really enjoyed Chicago a lot. We went on several super
architectural tours, spent a day in the art museum (the Chicago Art
Institute), saw a couple of plays, and more. We're hoping to go
back again.
More later when I've had a chance to catch up.
- Dave
[snip]
--
Dave Kuhlman
http://www.rexx.com/~dkuhlman------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
