316817 - [newwidget] Output which parses DOM data and displays it

Status: RESOLVED FIXED

(Core Graveyard :: XForms, enhancement, P5)

Description

[Splash]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.8) Gecko/20051025 Firefox/1.5

I want to see feature for output some CDATA from xf:instance without escaping of XML entities.
F.e. <xf:output disable-output-escaping="yes" value="somenode"> for <somenode><![CDATA[<strong>Hello<strong>]]></somenode> will render bold text "Hello"

Reproducible: Always

Steps to Reproduce:

Comment 1

[Allan Beaufour]

Well, it's not "pure" XForms. What you actually want is not that it's not escaped (because it's not escaped, it's a string like everything else). You want it parsed as f.x. HTML, right?

Comment 2

[Allan Beaufour]

Attachment: Example

This is what you want, right? Please confirm.

Comment 3

[Allan Beaufour]

(In reply to comment #2)
> Created an attachment (id=203378) [edit]
> Example
> 
> This is what you want, right? Please confirm.

Heh. My "testcase-to-xhtml" stylesheet of course transformed the CDATA section, so that is actually not what you want I guess. Nevertheless, XForms clearly defines what a control is bound to:
http://www.w3.org/TR/xforms/slice8.html#ui-processing

Comment 4

[Splash]

Yes, it's right testcase.
I think right? <![CDATA[<]]> is equivalent to &lt; ?
There is problem: I don't know how to indicate what value of output must be parsed as HTML. May be via attribute @appearance on xf:output. It's present in recommendation.

Comment 5

[Splash]

(In reply to comment #3)
> Heh. My "testcase-to-xhtml" stylesheet of course transformed the CDATA section,
> so that is actually not what you want I guess. Nevertheless, XForms clearly
> defines what a control is bound to:
> http://www.w3.org/TR/xforms/slice8.html#ui-processing
> 
Recommendation f.x. doesn't clearly define behavior of parsing result of @value attribute on xf:output

Comment 6

[Allan Beaufour]

(In reply to comment #4)
> Yes, it's right testcase.
> I think right? <![CDATA[<]]> is equivalent to &lt; ?

Depends on how you view it, but if &lt;, etc. is fine for you I have a solution for you.

(In reply to comment #5)
> Recommendation f.x. doesn't clearly define behavior of parsing result of 
> @value attribute on xf:output

No but I think it would stop you from using CDATA.

Comment 7

[Allan Beaufour]

Attachment: Parsed output custom control

Here's an example of a custom control that makes output appearance="parsed" parse the content, and insert it in the DOM.

Refresh does unfortunately not work in FF1.5rc2... dunno why, I get a:
Error: [Exception... "'Permission denied to get property XMLDocument.firstChild' when calling method: [nsIXFormsUIWidget::refresh]"  nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "JS frame :: http://localhost/xftst/CustomControls/parsed-out.xhtml :: onblur :: line 1"  data: no]
Source File: http://localhost/xftst/CustomControls/parsed-out.xhtml
Line: 1

It works fine on a trunk build... same goes for styling, it does not look good on branch, we need "xf-value" support (bug 312980) on branch.

So if you want to toy around with this, you might have to use trunk for now.

Comment 8

[Splash]

You can include this custom control support into Core ?
I don't think what "parsed" is a reserved word for @appearance attribute :)

Comment 9

[Allan Beaufour]

(In reply to comment #8)
> You can include this custom control support into Core ?

Well well, everything's possible but once we have it in we have to support it, etc. I think we need a general decision on what we take in, and what we do not. For now, I think you have to include it in your own form.

> I don't think what "parsed" is a reserved word for @appearance attribute :)

Not yet :)

Comment 10

[Splash]

Thanx.
Yes, I will include that code in my form, but I think this is good thing and it may be need to someother.
PS What I must do with this bug?

Comment 11

[Allan Beaufour]

(In reply to comment #10)
> Thanx.
> Yes, I will include that code in my form, but I think this is good thing and it
> may be need to someother.

Yes, you are not the first one with that request. I've been thinking about doing a custom control for it for some time.

We have to decide on a "non-spec" policy, but I think this one (possibly with some changes) could go in. The XForms spec. does not say anything about how controls should look like, only hints, etc. So I guess we are not breaking the spec. by including this.

> PS What I must do with this bug?

Let's keep it open. I've changed the title, etc.

Comment 12

[Allan Beaufour]

Attachment: Revised example

Comment 13

[alexander :surkov (:asurkov)]

Can we use @mediatype for this instead @appearance attribute since mediatype is supported for xf:output starting with 1.1 specs? For example, we can use "application/xhtml+xml", "application/xml", "application/vnd.mozilla.xul+xml". Thoughts?

Comment 14

[aaronr]

My only issue with this bug is that by spec output can only bind to simpleContent.  Start throwing in element nodes and that will no longer hold true.  I like the mediatype approach.  That could help us determine what anonymous content to use for the getControlElement part of the XBL.

Comment 15

[alexander :surkov (:asurkov)]

(In reply to comment #13)
> Can we use @mediatype for this instead @appearance attribute since mediatype is
> supported for xf:output starting with 1.1 specs? For example, we can use
> "application/xhtml+xml", "application/xml", "application/vnd.mozilla.xul+xml".
> Thoughts?
> 

I invented a wheel, Allan did it already in his example 'Revised example' :)

Comment 16

[alexander :surkov (:asurkov)]

(In reply to comment #14)
> My only issue with this bug is that by spec output can only bind to
> simpleContent.  Start throwing in element nodes and that will no longer hold
> true. 

The bug is about to parse node value and therefore we can go ahead since type of such node is string. But you are right if instance node contains other nodes which we are trying to display. Btw, what type does instance node have if it contains other nodes?

Comment 17

[aaronr]

(In reply to comment #16)
> (In reply to comment #14)
> > My only issue with this bug is that by spec output can only bind to
> > simpleContent.  Start throwing in element nodes and that will no longer hold
> > true. 
> 
> The bug is about to parse node value and therefore we can go ahead since type
> of such node is string. But you are right if instance node contains other nodes
> which we are trying to display. Btw, what type does instance node have if it
> contains other nodes?
> 


It has a complexType with complexContent.

Comment 18

[Steve Speicher]

(In reply to comment #14)
> My only issue with this bug is that by spec output can only bind to
> simpleContent.  Start throwing in element nodes and that will no longer hold
> true.  I like the mediatype approach.  That could help us determine what
> anonymous content to use for the getControlElement part of the XBL.
> 

I agree that violating the spec is not desireable but I do think there is value in having output, or some other similar control, support complex content.

Take for example that tax example with pie chart.  Perhaps the XForm could have 2 instances: one being the tax data and the other an SVG image.  The SVG image could be displayed in an output like:
  <xforms:output ref="instance('inst_svg')" mediatype="application/xml" />

Then bind/calculates can be used to define the pie slices based on changes to the tax instance.

I think there are many other interesting scenarios that this could support though this exposes some potential for dom events.  Do the events occur from the output tag or from the instance tag in the model?  Was curious if anyone else thought this would be a valuable extension?

Comment 19

[Leigh L. Klotz, Jr.]

(In reply to comment #17)
 
> It has a complexType with complexContent.


It may be simpler to do just @mediatype="text/html" and deal with escaped text.
Then you avoid the complexContent issue.

The issue of whether @mediatype of text/* types is allowed under XForms 1.1 is on the agenda for discussion at the next XForms F2F, specifically to allow this case.

Also, please see RFC 4287 (ATOM) which defines both escaped HTML and application/xhtml+xml content models for its elements, keyed off an attribute value.  

I believe that xf:output/@mediatype='text/html' is likely to be supported cross-vendor under XForms 1.1, without the potential concerns associated with complex content.

Comment 20

[alexander :surkov (:asurkov)]

So, the widget is likely. But I don't think it's right to broke the specs. In any way anybody who wants to have it can implement own binding. But I guess we should raise the question on w3c. From point of view 1.1 specs it looks resonable.

But if instance node that contains CDATA section or escaped characketers has xsd:string type and value of instance node can be treated as html or xml. Therefore we can add the widget for that. But as far as I know DOMParser doesn't support 'text/html' (though I'm not sure it's still valid). So we can support something like 'text/xml'.

I think we should have separate bug for outputs with 'application/xml' mediatypes.

Comment 21

[Leigh L. Klotz, Jr.]

I doubt the XForms 1.1 rec will specically say what to do with @mediatype='text/html' but I hope that it will at least not disallow it, as it currently does.  

You bring up a good point: is a string with pointy brackets in it text/html or application/xhtml+xml.  So perhaps I'm wrong and it's probably a bad idea to distinguish point-bracket-text and complexContent with a MIME type; we'll find out after the F2F. 

But I still suspect that the retriction against binding to particular MIME types will go away, and I also doubt that binding to complexContent will happen in the XForms 1.1 timeframe.

Comment 22

[alexander :surkov (:asurkov)]

Attachment: patch

I saw several requests for the feature, so probably we do need to add it. Since we can't bind output to complex data therefore html should be placed inside CDATA section.

Aaron, is 0.8 freezed already?

Comment 23

[aaronr]

Comment on attachment 266755 [details] [diff] [review]
patch

Alex, can you please attach a testcase?  I don't see a problem with the patch, but I also don't have a way to test it.  Also, it would be good to have an example to point to when people want to know how to do this.  Thanks.

With a testcase, r=me

Comment 24

[alexander :surkov (:asurkov)]

Attachment: testcase

I didn't test it though (I have not right now build with xforms).

Comment 25

[aaronr]

Comment on attachment 266755 [details] [diff] [review]
patch

Guess this is waiting on a second review.  Olli?

Comment 26

[Olli Pettay [:smaug][[e-mail]]]

I checked this in.

Comment 27

[alexander :surkov (:asurkov)]

(In reply to comment #26)
> I checked this in.
> 

thank you

Comment 28

[aaronr]

checked into 1.8 branch via bug 410239.