Re: XForms schema: mustUnderstand and extension

Hi Mark,

Could you point us to an example of a form with xf:extension and what it 
would look like when rendered?  You are using xf:extension as like input 
data to the widget, then?  And the widget decides what to do with it?  I 
never thought of it that way, but that is a cool idea.  Kinda of like 
deciding which widget to use for an xforms element based on @appearance 
or the bound type.  An implementation could decide on the widget based 
on the type of data in the child xf:extension. In this usage, I think I 
agree with Mark that there should just be one per element...kind of like 
a label.

One interesting thing would be whether if you put an xf:extension of a 
xf:repeat, would you then end up with an xf:extension per repeat row, or 
  still just the one applying to the repeat?  I would think just one for 
the repeat and that there wouldn't be one per row.

Mozilla hasn't done anything with xf:extension, yet, but we are 
interested in the possibilities that it presents.

--Aaron

Mark Birbeck wrote:
> 
> Hi Jan,
> 
>> Does anyone disagree that extension
>> should be permitted as a child of *any* XForms element? What about as a
>> child of elements (i.e. setvalue) whose content models currently do not
>> permit other elements as children? Are multiple extension elements 
>> permitted
>> as a child of the same XForms element? Can the extension element appear
>> anywhere in the sequence of child elements?
> 
> It would be interesting to see how people have implemented
> xf:extension, in order to see what the options are.
> 
> What we've done in formsPlayer is to treat xf:extension just like an
> xf:instance that was 'local' to the parent element. At run-time we
> parse the contents of the xf:extension, and then create an attribute
> called 'extension' on the parent node, which contains a DOM with the
> contents of the xf:extension.
> 
> This is then available to any script, in particular to our XBL
> widgets, which makes it a very convenient way for an author to provide
> extra data for run-time use.
> 
> Taking this approach does mean for us though, that it would be more
> logical if only one xf:extension was allowed per element. But given
> that xf:extension wasn't defined very clearly in the first place, I'm
> not at all saying that our approach is supported by the spec--simply
> that this is the approach we took, to try to make something useful
> from xf:extension.
> 
> I'd be interested to hear how others have made use of xf:extension.
> 
> Regards,
> 
> Mark
>

Received on Thursday, 24 August 2006 22:33:13 UTC