Right, but my supposition is that there's enough information in the
LFC sources to create (most of) the in-core DOM tree using the same
mechanism. If <node> is in the base schema, then the schema rules for
<view> can be built by parsing the LFC. This would eliminate a class
of bugs and simplify the base schema enormously.
But I'm ready to believe I'm missing some fundamental gotcha that
prevents this from being feasible.
On Oct 30, 2006, at 1:20 PM, Henry Minsky wrote:
If I recall correctly, the way that the tag compiler works now,
when it sees a <class> tag, it
1) detemines the superclass name
2) looks in the schema DOM and finds the definition element that
represents the superclass
3) deep copies it
4) extends it with any new attributes that the new class declares
So the schema in-core DOM tree is dynamically extended with each
user class <class> tag
So to "bootstrap" the system, the schema has to be seeded with
some definition of each class that
you want to be able to extend in LZX.
'node' and 'view' are the most popular things to extend, but the
tag compiler can extend anything
that is declared in the base schema, since it just looks for the
superclass definition and clones it.
