Hi Holger, I didn't wait for this to settle for 1.1.0, but it can become available in 1.1.1 if we see it fit. Holger Joukl wrote:
Stefan Behnel wrote:
One thing that comes to my mind is that we could add support for replacing the default type classes used by ObjectifyElementClassLookup. We could add keyword arguments so that you could say
lookup = ObjectifyElementClassLookup(StringElement=MyStringElementClass) That would currently work for String-, None- and ObjectifiedElement only, as the others use the data type registry. Maybe we should rather support something like "default_data_class" and "default_tree_class" (and keep the NoneElement, which is only used in a well defined case anyway).
I chose "tree_class" and "empty_data_class" now. I think that's sufficiently telling.
I'm perfectly happy with the current solution except for setattr-ing a 'structural element' and wanting this to remain instead of becoming a StringElement. I don't quite see how a different default data class or different tree class achieve this?
Well, the idea is that you can change the default for empty data classes (remember that it's a pretty arbitrary decision to default to StringElement here) and also use subclasses of ObjectifiedElement for the tree structure. However, if you want StringElement in some cases and ObjectifiedElement in other cases, that's difficult to achieve at the Python level, as it would require passing information about the C node to allow taking the decision.
So I'm back to suggesting a TreeElement() factory (not the best name, maybe) returning an ObjectifiedElement with a new pytype='ObjectifiedElement' which keeps it from becoming a string. I think that's still nicer than "stringifying" every single empty leaf when parsing from XML.
What about adding the attribute in objectify.Element()? You can't normally change the data value of an Element itself, so the only real reason why you would call objectify.Element() is to create a structural element (usually a root node). I called the corresponding pytype value "TREE" for now, I think it's unlikely that someone would use that as custom type name. Stefan