309294 - make available nsIInstanceElementPrivate and nsIModelElementPrivate interfaces for JavaScript

Status: RESOLVED INVALID

(Core Graveyard :: XForms, defect)

Description

[alexander :surkov (:asurkov)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Components.interfaces.nsIInstanceElementPrivate and
Components.interfaces.nsIModelElementPrivate returns undefined.

For what I need that. Since nsIXFormsModelElement interface hasn't methods to
get all intstances then I forces to use nsIModelElementPrivate interface (bug
307093). When I get model node then it hasn't methods of nsIModelElementPrivate.
I should be able to query this interface.

Reproducible: Always

Comment 1

[Allan Beaufour]

(In reply to comment #0)
> Components.interfaces.nsIInstanceElementPrivate and
> Components.interfaces.nsIModelElementPrivate returns undefined.
> 
> For what I need that. Since nsIXFormsModelElement interface hasn't methods to
> get all intstances then I forces to use nsIModelElementPrivate interface (bug
> 307093). When I get model node then it hasn't methods of nsIModelElementPrivate.
> I should be able to query this interface.

They will never be "scriptable", which is what you ask for. That's the reason
they are called "Private". What you need is an extension of the scriptable
interface that is exposed, ie. bug 307093. If you have any suggestions to
exactly how the functions should look like / behave, please write it on that bug.



*** This bug has been marked as a duplicate of 307093 ***

Comment 2

[alexander :surkov (:asurkov)]

I don't agree.

1) I belive nsIXFormsModelElement should have methods not only like in bug
307093. I refered to a those methods for example. Actually now I need
setNodeValue()/getNodeValue() methods. Threafore it is not exactly dupe of the
bug 307093. Actually we can enlarge bug 307093 to track all proposes about
interface nsIXFormsModelElement (i.e. what methods nsIXFormsModelElement should
realize).

2) Since the bug 307093 is proposes only and it is not w3c spec :) then it will
be fixed some years after. What I should do now? In other hand
nsIModelElementPrivate give me all what I need. If I can query this interface
from c++ why I cannot to query it from javascript? Can we make it available for
JavaScript at least temporary? If you don't want to make available it for
JavaScript in any case then please mark the bug as invalid.

Comment 3

[alexander :surkov (:asurkov)]

Mark invalid.

Comment 4

[Allan Beaufour]

(In reply to comment #2)
> 1) I belive nsIXFormsModelElement should have methods not only like in bug
> 307093. I refered to a those methods for example. Actually now I need
> setNodeValue()/getNodeValue() methods. Threafore it is not exactly dupe of the
> bug 307093. Actually we can enlarge bug 307093 to track all proposes about
> interface nsIXFormsModelElement (i.e. what methods nsIXFormsModelElement should
> realize).

You need a lot of stuff, and I will be glad to help you all that we can, taking
into account that we base this implementation on standards.

> 2) Since the bug 307093 is proposes only and it is not w3c spec :) then it will
> be fixed some years after. What I should do now? In other hand
> nsIModelElementPrivate give me all what I need. If I can query this interface
> from c++ why I cannot to query it from javascript? Can we make it available for
> JavaScript at least temporary?

Temporary means "forever" in most practical cases, because once we expose it
people will use it, and people will scream if we then remove it (understandable).

> If you don't want to make available it for
> JavaScript in any case then please mark the bug as invalid.

IMHO there's quite the difference between exposing it to C++ and to javascript.
Javascript can be reached by the form author, C++ only by browser/extension code.

The enumeration definition will not take years, it'll get there.

You seem to be moving on "the edge" of what XForms was designed for. We will
focus on getting it to work for "plain XHTML" first, then we'll get to the more
"funky" stuff. That said, what you do looks interesting and I would like to help
in any way I can, but there are more important things right now.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #4)

> The enumeration definition will not take years, it'll get there.
> 
> You seem to be moving on "the edge" of what XForms was designed for. We will
> focus on getting it to work for "plain XHTML" first, then we'll get to the more
> "funky" stuff. That said, what you do looks interesting and I would like to help
> in any way I can, but there are more important things right now.

Yes, I think too I work with XForms on "the edge". I use XForms as technology
for distinguishing of data from it's presentation. And I use it for application
creating. I understand at first XForms realization should do what XForms is
designed for. But if XForms can be used on "the edge" then it will be more
powerful. If I will be honestly then I think future of XForms is not data
submission only, but as technology of data distinguishing from it's presentation. 

Thanks for collaboration.

Comment 6

[Allan Beaufour]

(In reply to comment #5)
> (In reply to comment #4)
> 
> > The enumeration definition will not take years, it'll get there.
> > 
> > You seem to be moving on "the edge" of what XForms was designed for. We will
> > focus on getting it to work for "plain XHTML" first, then we'll get to the more
> > "funky" stuff. That said, what you do looks interesting and I would like to help
> > in any way I can, but there are more important things right now.
> 
> Yes, I think too I work with XForms on "the edge". I use XForms as technology
> for distinguishing of data from it's presentation. And I use it for application
> creating. I understand at first XForms realization should do what XForms is
> designed for. But if XForms can be used on "the edge" then it will be more
> powerful. If I will be honestly then I think future of XForms is not data
> submission only, but as technology of data distinguishing from it's presentation. 

I can only agree, and I would love to see XForms evolve to something that can be
used for your purpose, but let's get the basics working first.

You and Olli are probably going down the same road (see bug 305763), and I would
like to see that happen, so do not loose faith in it :) I'll help all I can time
and priorities taken into consideration.

> Thanks for collaboration.

No problem. Thanks for your input and thoughts, keep them coming.