I've read a lot of stuff regarding the use of unstructured and
avoiding structured node types as long as possible.  I think I have a
compelling reason to use a structured node type pretty early in my
project . . . I'd like some thoughts from others who've been down this
road.

I want to be enable a sort of run time awareness of the structure of
documents in my CMS.  I'd like to be able to add custom document
types, defined as node types, and have my system just handle them.  To
do this, it seems necessary for the code to be able to "inspect" the
structure of the document, e.g. learn what attributes is has in order
to become aware of the document's structure so that I can render edit
or create wizards the appropriate fields -- correspondent to the
attributes of the node type that backs the document being created.  I
can't really see how I can pull this off without have structured node
types.  If you see a alternative, let me know.

Additionally, I don't see much threat in defining non-mandatory
properties and children nodes.  It seems that this wouldn't pose any
data migration issues, which are the main danger behind getting into a
structured model, correct?  Thoughts?

Reply via email to