306526 - xforms controls should be able to be extended by elements of other namespace

Status: RESOLVED WONTFIX

(Core Graveyard :: XForms, enhancement)

Description

[alexander :surkov (:asurkov)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050821 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050821 Firefox/1.6a1

XForms control arn't able to provide custom presentation of instance data of
model. It would be gracefully to allow for elements from any namespace to be
used together with xforms controls. In other words I want to modify instance
data by using arbitrary elements. 

It means element from other namespace should implements interfaces
nsIXFormsUIWidget and nsIXFormsDelegate (maybe something else?). If such things
would be realized then programmers whould be able to write own xbl (like
xforms:input xbl or xforms:output xbl).

There is a question: how to specify that some element should implements xforms
interfaces? As I know since xforms:extention is not assigned for this then you
can reserve a tagname. When XFroms Processor will find element with the tagname
then it will add a realization of needed interfaces to element. Since xforms
controls has different attributes set (Common, UI Common, Single Node Binding) 
then maybe it's needed to reserve a several tagnames. "if

Reproducible: Always

Comment 1

[alexander :surkov (:asurkov)]

Maybe something like this is presented already in current realization of xforms? 

Comment 2

[alexander :surkov (:asurkov)]

Aaron Reed wrotes:

> If all you want to do is update instance data from some other control, it is 
> simple enough to do using script and seems to have been anticipated by the 
> XForms authors. If you look at: 
> http://www.w3.org/TR/xforms/index-all.html#expr-instance, you can use the 
> model interface (in our tree it is is defined in nsIXFormsModelElement.idl) to 
> get the instance document that you desire from a particular model. Then just 
> treat the returned instance document like any other nsIDOMDocument to 
> find/add/remove/update any node that you desire. Make sure when you are done 
> making changes to the document that you then perform a rebuild(), 
> recalculate(), revalidate() and refresh() in that order, for this model 
> element. Any change that you made to the instance data should then be 
> reflected in the form.

> Combine this type of scripting with XBL and you should get the result that you 
> are looking for, I think.


I want to update some control from instance too (setting initial value and
updating control if instance data was chagend by somebody).
 
As I understand you propose to work with model instance interface. But xforms
xbls (like input or output) works with model instance by using nsIXFormsDelegate
interface. I guess nsIXFormsDelegate is used to provide a link with instance
data in two directions (from instance data to control element and from control
element to instance data). I want to get interface to provide behaviour for some
other element as for xforms controls. I guess it would be more hady than use of
model instance interface.

Comment 3

[alexander :surkov (:asurkov)]

If I'm not wrong then all what I want is presented in specification
(http://www.w3.org/TR/2003/REC-xforms-20031014/slice7.html#ui-binding-foreign):

> The XForms binding mechanism allows other XML vocabularies to bind user 
> interface controls to an XForms Model using any of the techniques shown here. 
> As an example, XForms binding attribute bind might be used within XHTML 1.x 
> user interface controls as shown below.
> <html:input type="text" name="..." xforms:bind="fn"/>

What means the sepcs topic? Is it means html:input should implements some
interfaces typical for xforms controls? If it is true then what interfaces?

Comment 4

[Allan Beaufour]

(In reply to comment #3)
> If I'm not wrong then all what I want is presented in specification
> (http://www.w3.org/TR/2003/REC-xforms-20031014/slice7.html#ui-binding-foreign):
> 
> > The XForms binding mechanism allows other XML vocabularies to bind user 
> > interface controls to an XForms Model using any of the techniques shown here. 
> > As an example, XForms binding attribute bind might be used within XHTML 1.x 
> > user interface controls as shown below.
> > <html:input type="text" name="..." xforms:bind="fn"/>
> 
> What means the sepcs topic? Is it means html:input should implements some
> interfaces typical for xforms controls? If it is true then what interfaces?

I guess that there would need to be a spec. for how the interaction should be
between XHTML and XForms. That does, to my knowledge, not exist (yet). As I read
the above paragraph, it just opens the possibility of doing bindings in foreign
namespaces.

What exactly are you trying to do, that you cannot do using the custom control
API? Do you have a use case / an example?

Comment 5

[aaronr]

> 
> What exactly are you trying to do, that you cannot do using the custom control
> API? Do you have a use case / an example?

Here is a link to what Allan was mentioning:
http://developer.mozilla.org/en/docs/XForms:Custom_Controls

Comment 6

[alexander :surkov (:asurkov)]

If I want to define custom behaviour for some xforms control (like output or
input controls) then I can add just a new binding (like in
http://developer.mozilla.org/en/docs/XForms:Custom_Controls). But if I like to
create my own element by using xbl for operations with xforms instance data then
what should I do? That is if I like to use some element with tagname different
from tagnames of xforms controls then how can I use custom control API?

If I understand right then my element should have implementation of
nsIXFormsDelegate interface to works with instance data. If is it true then, in
instance, when I add a new binding to xforms:output element then I get something
more than implementation of nsIXformsDelegate. But I don't need 'something more
than implementation of nsIXformsDeletegate'.

Comment 7

[Allan Beaufour]

(In reply to comment #6)
> If I want to define custom behaviour for some xforms control (like output or
> input controls) then I can add just a new binding (like in
> http://developer.mozilla.org/en/docs/XForms:Custom_Controls). But if I like to
> create my own element by using xbl for operations with xforms instance data then
> what should I do? That is if I like to use some element with tagname different
> from tagnames of xforms controls then how can I use custom control API?

Ok, I think I understand what you want. You want to have f.x.
<foo:supertag/> (where foo is != xforms namespace)
bound by xbl to something, and also have it bound to an XForms instance node, so
you'll can set and get data, and receive events?

If that's what you want, we do not have direct support for it for now. The best
hack I can think of is to "swallow" f.x. and XForms input with "display:none"
inside the XBL content, set its @ref and set/get values and states on that. NB!
This does not work right now though, we have a bug regarding xforms inside XBL.

We could also expose a "pure" nsIXFormsDelegate with no UI for you, instead of
the "display: none" hack. But most of all, I would like to see a common
cross-processor implementation.

Comment 8

[aaronr]

I don't know if it was covered by Allan's event comment or not, but we'll also
have to add the instance-bound element to the model list so that the model knows
to call refresh() on it.  As a work around now, a user could probably put DOM
mutation event listeners on the instance document to catch when their bound node
has changed and update the non-xforms elements themselves.

Comment 9

[alexander :surkov (:asurkov)]

(In reply to comment #7)

> Ok, I think I understand what you want. You want to have f.x.
> <foo:supertag/> (where foo is != xforms namespace)
> bound by xbl to something, and also have it bound to an XForms instance node, so
> you'll can set and get data, and receive events?

Yes. That's what I want. In instance, if <foo:element> has ref or bind
attributes of xforms namespace then <foo:element> implements some interfaces to
set/get data and recive events. 

What means 'f.x.'?

> This does not work right now though, we have a bug regarding xforms inside XBL.

Can you say me a bug number?

> We could also expose a "pure" nsIXFormsDelegate with no UI for you, instead of
> the "display: none" hack. But most of all, I would like to see a common
> cross-processor implementation.

What element can provide to me a "pure" nsIXFormsDeletegate interface?

Comment 10

[Allan Beaufour]

(In reply to comment #9)
> (In reply to comment #7)
> 
> > Ok, I think I understand what you want. You want to have f.x.
> > <foo:supertag/> (where foo is != xforms namespace)
> > bound by xbl to something, and also have it bound to an XForms instance node, so
> > you'll can set and get data, and receive events?
> 
> Yes. That's what I want. In instance, if <foo:element> has ref or bind
> attributes of xforms namespace then <foo:element> implements some interfaces to
> set/get data and recive events. 

Would truly be a good feature, but I do not see it happening right away in Mozilla.

> What means 'f.x.'?

"For example", dunno if it's proper english though :)

> > This does not work right now though, we have a bug regarding xforms inside XBL.
> 
> Can you say me a bug number?

It's the one you reported yourself :) bug 306678. Or should I say: I think it
is. I haven't tested it yet.

> > We could also expose a "pure" nsIXFormsDelegate with no UI for you, instead of
> > the "display: none" hack. But most of all, I would like to see a common
> > cross-processor implementation.
> 
> What element can provide to me a "pure" nsIXFormsDeletegate interface?

Well, none for the moment, but we could expose one. So you could do this hack:
<content>
  <xforms:delegate id="xf" ref=/xx/yy"/>
  <boo:visual/>
</content>

You could then watch "xf" for events, and get and set .value on it.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to comment #10)

> > Yes. That's what I want. In instance, if <foo:element> has ref or bind
> > attributes of xforms namespace then <foo:element> implements some interfaces to
> > set/get data and recive events. 
> 
> Would truly be a good feature, but I do not see it happening right away in
Mozilla.
> 

Is it restriction of XTF because xtf binding is applied only for specified tagname?

Comment 12

[alexander :surkov (:asurkov)]

(In replay to comment #7 )

> The best hack I can think of is to "swallow" f.x. and XForms input with 
> "display:none" inside the XBL content, set its @ref and set/get values and 
> states on that. NB! This does not work right now though, we have a bug 
> regarding xforms inside XBL.

(In replay to comment #9 )

> It's the one you reported yourself :) bug 306678. Or should I say: I think it
> is. I haven't tested it yet.

I wrote the next test. Thease things are different.

<binding id="alertvalue">
<content>
	<xf:input xbl:inherits="bind, ref" xul:hidden="true" anonid="delegate"/>
	<xul:button label="hello"/>
</content>
<handlers>
	<handler event="command">
		alert(document.getAnonymousElementByAttribute(this, 'anonid',
'delegate').delegate.value);
	</handler>
</handlers>
</binding>

<alertvalue ref="/x/y" style="-moz-binding: url('#alertvalue')">

When I click on button then I see alert with correct value.

Comment 13

[alexander :surkov (:asurkov)]

The present bug is about it's needed a way to create controls for instance data work. If control of custom namespace will be able to be work with instance data then it will be splendidly. But xtf doesnt allow to do it. But if element has xforms namespace then I guess the idea can be realized by the following way. If xforms factory doesn't find known tagname then it creates nsXFormsDelegateStub as xtf binding. If I'm not wrong then it should work. If such idea doesn't conflict with xforms idea and if the proposed way will work then I can post new bug and file the patch. Please let me know your opinion about it.

Comment 14

[Allan Beaufour]

(In reply to comment #13)
> The present bug is about it's needed a way to create controls for instance data
> work. If control of custom namespace will be able to be work with instance data
> then it will be splendidly. But xtf doesnt allow to do it. But if element has
> xforms namespace then I guess the idea can be realized by the following way. If
> xforms factory doesn't find known tagname then it creates nsXFormsDelegateStub
> as xtf binding. If I'm not wrong then it should work. If such idea doesn't
> conflict with xforms idea and if the proposed way will work then I can post new
> bug and file the patch. Please let me know your opinion about it.

We should not create elements for "whatever tagname", only for defined XForms elements. That seems quite logic to me. We should either support (XForms namespaced) @ref/@bind on all elements, or have the "XForms stub" that you can embed in your custom control. Or both.

Comment 15

[alexander :surkov (:asurkov)]

(In reply to comment #14)
> 
> We should not create elements for "whatever tagname", only for defined XForms
> elements. That seems quite logic to me. We should either support (XForms
> namespaced) @ref/@bind on all elements, or have the "XForms stub" that you can
> embed in your custom control. Or both.
> 

I guess "XForms stub" element embeded in custom control isn't very comportable thing because it involves code increases and duplicates. As opposed to xforms stub @ref/@bind attributes don't have mentioned disadvantages. But such way not reachable now. Although I gues "xforms stub" (in instance xforms:delegate element) is better than xforms:input using as "xforms stub". Should I file a bug? ;)

Allan, do you have in view there are xforms elements so that they don't realize nsIXFormsDelegate interface?

Comment 16

[Allan Beaufour]

(In reply to comment #15)
> (In reply to comment #14)
> > 
> > We should not create elements for "whatever tagname", only for defined XForms
> > elements. That seems quite logic to me. We should either support (XForms
> > namespaced) @ref/@bind on all elements, or have the "XForms stub" that you can
> > embed in your custom control. Or both.
> > 
> 
> I guess "XForms stub" element embeded in custom control isn't very comportable
> thing because it involves code increases and duplicates. As opposed to xforms
> stub @ref/@bind attributes don't have mentioned disadvantages. But such way not
> reachable now. Although I gues "xforms stub" (in instance xforms:delegate
> element) is better than xforms:input using as "xforms stub". Should I file a
> bug? ;)

Well, haven't we talked about this before? We need "xtf for attributes" for this and attribute-based repeats. It's way out in the future in my view.

> Allan, do you have in view there are xforms elements so that they don't
> realize nsIXFormsDelegate interface?

I do not understand what you mean here.

Comment 17

[alexander :surkov (:asurkov)]

(In reply to comment #16)
> 
> Well, haven't we talked about this before? We need "xtf for attributes" for
> this and attribute-based repeats. It's way out in the future in my view.

Yes, xtf for attributes is a best solution. I have in view now we need have a stub to write new controls. Thus I can use xf:input instead of special stub. Probably it's a good to create special element for such proposes. Probably isn't.

> > Allan, do you have in view there are xforms elements so that they don't
> > realize nsIXFormsDelegate interface?
> 
> I do not understand what you mean here.
> 

Don't take into account. I thought all xforms elements (nodes of xforms namespace) realize nsIXFormsDelegate interface. I was wrong.

Comment 18

[David Bolter [:davidb] (NeedInfo me for attention)]

RIP xforms