313113 - Expose interface for model item properties modfying

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.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

When I want to modify some MIP for instance data then I should pass the follwing
steps:
1) If bind element is absent then I should create it. 
2) I should set desired attributes. 
3) I should update model. Note when I'll update the model then all binded
controls will be updated too. I need update controls wich is binded to modified
bind.

I think it's not very compfortable. It would be gracefull if I can be able to do
it by calling one methods of some interface.

Reproducible: Always

Comment 1

[alexander :surkov (:asurkov)]

(In reply to comment #0)

> When I want to modify some MIP for instance data then I should pass the
> follwing steps:
> 1) If bind element is absent then I should create it. 
> 2) I should set desired attributes.
> 3) I should update model. Note when I'll update the model then all binded
> controls will be updated too. I need update controls which is binded to modified
> bind.

Probably the proposed interface should be replaced by dynamic bind elements handling because the bug 316967 is appealed to solve the step 3 and special
interface for 1 and 2 step handling is not needed a much.

But I want to have a way to modify MIPs on instance data directly. When I modify  instance document then sometimes I need to change MIPs values for instance nodes. In this case I can get into difficulties when I'm not able to obtain xpath expression for desired instance node and threafore I'm not able to add/change bing element.

Comment 2

[Allan Beaufour]

(In reply to comment #1)
> (In reply to comment #0)
> 
> > When I want to modify some MIP for instance data then I should pass the
> > follwing steps:
> > 1) If bind element is absent then I should create it. 
> > 2) I should set desired attributes.
> > 3) I should update model. Note when I'll update the model then all binded
> > controls will be updated too. I need update controls which is binded to modified
> > bind.
> 
> Probably the proposed interface should be replaced by dynamic bind elements
> handling because the bug 316967 is appealed to solve the step 3 and special
> interface for 1 and 2 step handling is not needed a much.

Only updating controls that are "bound to the new bind", is more tricky than so. If you insert a bind, it might influence other nodes through f.x. the calculate property or inheritance. We need to do partial updates of the MDG, etc. Oh wee. I do not see myself doing that in the near future :)

> But I want to have a way to modify MIPs on instance data directly. When I
> modify  instance document then sometimes I need to change MIPs values for
> instance nodes. In this case I can get into difficulties when I'm not able to
> obtain xpath expression for desired instance node and threafore I'm not able
> to add/change bing element.

We've talked about this before, and it very much "not XForms". MIP values are set through binds.

Comment 3

[alexander :surkov (:asurkov)]

I'm sure as before it's nice feature of "xforms for apps". I'm agree xforms allow to define MIPs by xf:bind element only and therefore we can implement this by adding new functionality around xf:bind elements. For that we should generate xpath for instance node and then we should just insert new bind element and then update the model. Probably we should provide interface to keep that binds together. Something like:

interface nsIXFormsBindElement; // allows to get and modify MIP

interface nsIXFormsNSModelElement {
 // bla bla bla
 nsIXFromsBindElement getBindElementForNode(in nsIDOMNode node);
 nsIXFormsBindElement getBindElementByExpr(in nsString string);

 nsIDOMNodeList getBindElements();
};

Comment 4

[alexander :surkov (:asurkov)]

(In reply to comment #3)
> For that we should
> generate xpath for instance node 

The bug 208500 has something to create xpath for node.

Comment 5

[Allan Beaufour]

(In reply to comment #3)
> I'm sure as before it's nice feature of "xforms for apps". I'm agree xforms
> allow to define MIPs by xf:bind element only and therefore we can implement
> this by adding new functionality around xf:bind elements. For that we should
> generate xpath for instance node and then we should just insert new bind
> element and then update the model. Probably we should provide interface to keep
> that binds together. Something like:
> 
> interface nsIXFormsBindElement; // allows to get and modify MIP
> 
> interface nsIXFormsNSModelElement {
>  // bla bla bla
>  nsIXFromsBindElement getBindElementForNode(in nsIDOMNode node);
>  nsIXFormsBindElement getBindElementByExpr(in nsString string);
> 
>  nsIDOMNodeList getBindElements();
> };
> 

As I said in comment 2, inserting a new bind requires a rebuild of the entire model. And should the bind not exist as a DOM node then? My take would be be that the author should create the DOM node, and then get the properties from that.

Comment 6

[aaronr]

(In reply to comment #5)
> (In reply to comment #3)
> > I'm sure as before it's nice feature of "xforms for apps". I'm agree xforms
> > allow to define MIPs by xf:bind element only and therefore we can implement
> > this by adding new functionality around xf:bind elements. For that we should
> > generate xpath for instance node and then we should just insert new bind
> > element and then update the model. Probably we should provide interface to keep
> > that binds together. Something like:
> > 
> > interface nsIXFormsBindElement; // allows to get and modify MIP
> > 
> > interface nsIXFormsNSModelElement {
> >  // bla bla bla
> >  nsIXFromsBindElement getBindElementForNode(in nsIDOMNode node);
> >  nsIXFormsBindElement getBindElementByExpr(in nsString string);
> > 
> >  nsIDOMNodeList getBindElements();
> > };
> > 
> 
> As I said in comment 2, inserting a new bind requires a rebuild of the entire
> model. And should the bind not exist as a DOM node then? My take would be be
> that the author should create the DOM node, and then get the properties from
> that.
> 


another thing to consider is that if a user is going to insert a control to point to this new bind...if he inserts the control before he inserts the bind element, then it will be pointing to an invalid bind and we have to throw a binding exception.  So the ordering of things will have to be well documented along with all of the possible errors that could happen.

Comment 7

[alexander :surkov (:asurkov)]

So, if we will be about to support this sometime then we should fix bug 316967 before.

Comment 8

[alexander :surkov (:asurkov)]

(In reply to comment #7)
> So, if we will be about to support this sometime then we should fix bug 316967
> before.
> 

For sure only if bug 316967 is not wontfix. Automatic keeping of changes is beautiful thing until it makes xforms processor to work a long time. If so then we changes should be grouped by rrr calls. And if so then probably can the dynamical changes handling be optional stuff?

> As I said in comment 2, inserting a new bind requires a rebuild of the entire
> model.

We should not require total rebuild in ideal situation (I don't have in view how rebuild() works), right?

> And should the bind not exist as a DOM node then? My take would be be
> that the author should create the DOM node, and then get the properties from
> that.

But if we won't create new bind element then the idea loose a part of it's beauty because I can't set MIPs if I have only instance node.

Comment 9

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

RIP xforms