[lxml-dev] Instantiated ObjectifiedElement

[Evan Grim]

>

First of all, thank you for your thorough reply.  I'll attempt to explain
myself better by addressing your input inline below.

Stefan Behnel <stefan_ml <at> behnel.de> writes:

> 
> Hi,
> 
> Evan Grim wrote:
> > I've run into some curious behavior when trying to do something a bit
> > non-standard with objectify.  The code snippet below causes a hard
crash.  I
> > know this isn't part of what is anticipated as normal use, but since it
causes a
> > crash I figure it's worth bringing up here to at least get some
comments.
> > 
> > <code>
> > from lxml import etree, objectify
> > 
> > class parent(objectify.ObjectifiedElement):
> >     pass
> > 
> > p = parent()
> > print p.tag
> > </code>
> 
> A crash is the expected result here. The docs say:
> 
> """Note that you cannot (or rather must not) instantiate this class
yourself.
> lxml.etree will do that for you through its normal ElementTree API.
> """
> 
> http://codespeak.net/lxml/element_classes.html
> 

I realized that instantiation is not the typical way to use these classes,
but had forgotten that the documentation was so explicit.  Thanks for
jogging my memory.  I haven't had a chance to look at the underlying code,
but if it isn't too difficult wouldn't an AssertionError (or some other
exception) be better than crashing?

> > My use case here is that I'm trying to make a package that acts like
objectify,
> > but enforces schema restrictions.
> 
> Not sure what exactly you mean. Do you mean data types, structural
validity,
> or both? How would you enforce restrictions during multi-step changes to
the
> tree, where the first couple of steps do not result in a valid tree by
themselves?

I'm shooting for all of the above.  Elements would not accept any changes
that would make them deviate from what is specified by their respective
schema definition.  Multi-step changes are definitely a tricky wicket when
it comes to this approach, but (at least for the use-cases I'm encountering)
can be handled by careful interface designs that make sure the library user
has all the tools they need.

> 
> Doesn't validation do what you want?

lxml's validation capabilities are great for document level validation.  But
what I'm wanting deviates from the current etree/objectify in what I believe
is currently an incompatible way:  I want to be able to go beyond document
level validation and instantiate the various types defined within the schema
as individual objects that can be modified and added to other
schema-type-based objects and all the while ensuring the schema rules are
never violated.

As an aside related to validation: I notice that xsd:unique tags aren't
validated [ref: http://www.w3.org/TR/xmlschema-0/#specifyingUniqueness].  Is
this planned for the future?  Are there any other XMLSchema gotchas of which
I should be aware?

> 
> > I'm trying my hand at writing custom classes
> > that will do this, but maintain the nice interface that objectify
provides.
> 
> That should be doable without instantiating any classes directly. Just
> override __setattr__ and __setitem__ and intercept the cases where
attributes
> are assigned. Use your subclasses as described here:
> 
> http://codespeak.net/lxml/objectify.html#advanced-element-class-lookup
>
http://codespeak.net/lxml/element_classes.html#setting-up-a-class-lookup-sch
eme

This is originally the tack I was taking, but quickly ran into the issue of
not being able to instantiate the objects in the manner I discuss above.
Since running into this problem I've taken to using a custom class for each
type that acts an intermediary to an underlying lxml element.

> 
> Stefan
> 

Thanks again for your input on this.  And while I've got the mic: thanks to
all who've put together a great xml suite.  I'm very grateful to no longer
be strapped to minidom.

Cheers,
Evan