Yes, it makes more sense, but I might go back to the drawing board for
a bit -- this sort of inheritance gets ugly in XSL. Assuming there
are the appropriate public methods, it might be better to work
directly against the live IndexSchema rather than by XSLT transforming
the schema.xml file. The drawback, of course, is that you cannot swap
in your own XSLT to make your own look and feel, which seems to be the
direction many people want to go with the admin tools. Any opinions
as to how important that ability is?
-Greg
On 12/8/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: What do you mean by inheritng/overriding? Granted, I am only working
: with the example schema here, but I do not see any similarities
: between the attributes of a field, and the fieldtype. For fieldtypes,
Doh! ... you're right ... there aren't any examples of what i'm talking
about in the sample schema.xml.
Basically, any "core" boolean attribute that can be set on a <field> can
be set on a <fieldtype>, by default a field inherits all of it's
attributes from the <filedtype> it uses, this is touched on briefly in the
SchemaXml wiki page...
Individual fields can override the various options (indexed, stored,
etc...) that they inherit from their fieldtype.
(it just so happens that the CNET schema we used as a template for hte
orriginal example schema.xml didn't excercise this feature)
looking at the code, the only core attribute of a <fieldtype> that can't
be overridden by a <field> is "positionIncrementGap" (and i think that has
more to do with it being a numeric attribute then anything else. If you
define a new custom FieldType with custom attributes, those wouldn't
overridable by the <field> either.
I'll make a note on the TaskList that we should both document this a
little better (and add some examples to the schema.xml)
...does what i was suggesting earlier make more sense now?
-Hoss
