Make calculate MIP return nodesets

RESOLVED WONTFIX

Status

Core Graveyard
XForms
--
enhancement
RESOLVED WONTFIX
12 years ago
a year ago

People

(Reporter: surkov, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.27 KB, application/xhtml+xml
Details
(Reporter)

Description

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

Now node value for calculate is rated as textnode. I guess it will be cool if node value will be rated as node too. It means when the first node contains non text child nodes then the second (calculated) should contain the same child nodes. Thus I guess if calculated node has 'string' data type then behaviour should be leaved as it is. Threafore probably we should have new data type ('nodeset' or something like) to provide new behaviour. Any thoughts?

Reproducible: Always

Comment 1

12 years ago
I don't see anything in the spec to prevent this behavior.  Your idea makes sense,  too.  But I think this would be something best defined by the working group since they allow all the different types but they don't say how to handle the different types.  Have you tried this on formsPlayer or XSmiles to see what they do?  It also would help if you attached a simple testcase.  Then you can just point the WG to this bug with the example already attached.  Much easier to discuss a concrete testcase than 'what if' types of questions :)

Comment 2

12 years ago
I was talking to David about this.  Another problem with inserting nodes under nodes if calculate returns a nodeset is anticipating when to do the rebuild on the model.  We could queue up a 'rebuild' on the model and have it run when the 'recalculate, revalidate, refresh' sequence has run.  Which we can almost guarentee will happen if such matters were only managed by the processor.  But if the recalculate that caused this calculate to return a nodeset was triggered by a script author, there is no guarentee that all the events will be run so that 'rebuild' could just be left hanging and not run promptly which would cause the MDG to behave unpredictably.

I will write the WG to see what they say.
(Reporter)

Comment 3

12 years ago
Created attachment 209047 [details]
testcase
(Reporter)

Comment 4

12 years ago
(In reply to comment #1)

It looks formsPlayer and XSmiles have the same behaviour like mozilla xforms. 

Can you point a link on WG discussion when you'll post it?

Comment 5

12 years ago
(In reply to comment #4)
> (In reply to comment #1)
> 
> It looks formsPlayer and XSmiles have the same behaviour like mozilla xforms. 
> 
> Can you point a link on WG discussion when you'll post it?
> 

Sorry, without thinking I posted this issue to the W3C XForms internal mailing list which you probably can't see unless you are a W3C member.  While not publicly visible, queries here tend to get more feedback from the WG than the public list.  I'll be sure to post the outcome to this bug.  If you want status at any time before that, please contact beaufour or me directly and we'll give you a summary of the thread at that moment.

Comment 6

12 years ago
First, this would break the behaviour that XForms has now, so it should at least be another attribute/tag -- and comment 2 also highlights other problems. Second, I'm not sure I see the use of this? You are essentially just copying (duplicating) nodes from one place to another all the time. Why?
(Reporter)

Comment 7

12 years ago
(In reply to comment #6)
> First, this would break the behaviour that XForms has now, so it should at
> least be another attribute/tag 

How about if result of calculate property will have a dependency from type? It breaks too but I can see the some beautiful in this.

> Second, I'm not sure I see the use of this? You are essentially just copying
> (duplicating) nodes from one place to another all the time. Why?
> 

Probably it makes sense when calculate property copies nodes from one instance to other. 

Actually I want to have the way to transform nodeset to other as for example it do xslt i.e I want to have the calculate possibilies for nodes. Can xforms have dependence from xslt or can nodeset transformations be achived by some other way? How the idea about nodes transformations looks in the light of xforms ideology?

Comment 8

12 years ago
(In reply to comment #7)
> (In reply to comment #6)
> > First, this would break the behaviour that XForms has now, so it should at
> > least be another attribute/tag 
> 
> How about if result of calculate property will have a dependency from type? It
> breaks too but I can see the some beautiful in this.

Me too, but breaking old functionality is a no go.
 
> > Second, I'm not sure I see the use of this? You are essentially just copying
> > (duplicating) nodes from one place to another all the time. Why?
> > 
> 
> Probably it makes sense when calculate property copies nodes from one instance
> to other. 

You should be able to do that with insert/delete. Not as smooth as your example, but it's possible. In 1.0 you have to do some "magic" for handling the empty nodeset, but 1.1 should allow for better handling.

> Actually I want to have the way to transform nodeset to other as for example it
> do xslt i.e I want to have the calculate possibilies for nodes. Can xforms have
> dependence from xslt or can nodeset transformations be achived by some other
> way? How the idea about nodes transformations looks in the light of xforms
> ideology?

Having some xslt functionality would be a nice XForms extension. But we still have some way to go for the standard functionality.

For now you will have to do insert/delete/setvalue to achieve some of it.

Updated

12 years ago
Severity: normal → enhancement
Summary: calculate for node → Make calculate MIP return nodesets

Updated

12 years ago
Assignee: aaronr → xforms
RIP xforms
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.