[lxml-dev] Instantiated ObjectifiedElement

[Stefan Behnel]

Hi,

Evan Grim wrote:
> Stefan Behnel <stefan_ml <at> behnel.de> writes:
>> Evan Grim wrote:
>>> <code>
>>> from lxml import etree, objectify
>>>
>>> class parent(objectify.ObjectifiedElement):
>>>     pass
>>>
>>> p = parent()
>>> print p.tag
>>> </code>
> 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?

Sure, if you tell me how to do that without a performance impact? But the
bigger problem is that you can't easily distinguish between an instantiation
from within lxml and an instantiation by user code.


> 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.

Then I'd say validity checks should be in the 'tools' as well.


> 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.

I don't know your specific setup, but you can always apply a part of a schema
to a specific Element.


> 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?

That's quite possible. libxml2's XML schema implementation is not 100%
complete. But that's nothing that can be changed in lxml.


>> http://codespeak.net/lxml/objectify.html#advanced-element-class-lookup
>> http://codespeak.net/lxml/element_classes.html#setting-up-a-class-lookup-scheme
>
> 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.

Mapping the types defined in a schema to the Elements in an XML tree is a
topic that has been suggested a couple of times already. lxml's Element class
lookup mechanisms allow for pretty sophisticated uses, but there isn't an
automatic way to assign classes from schema types. You'll have to do that
yourself.

Stefan