Inserting XFORM data into XHTML using variables

Henrik,

You have to do that with xforms:output since (x)html tag does not 
'understand' what is xforms:instance

Something like that :
<xforms:output value="concat(
                                              '&lt;src=&#34;',
                                              instance('my-image')/location,
                                              '&#34;/&gt;')"
                                              mediatype="text/html"/>

HTH,

  

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
  

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Friday, December 01, 2006 8:33 AM

Subject: Re: [ops-users] Inserting XFORM data into XHTML using variables

All,

I am attempting to output some div tags with dynamic attribute 'title' (from an instance).

This is how I am doing it:
===================
<xforms:output value="concat('&lt;xhtml:div id=&#34;error-context&#34; title=&#34;', 'testing', '&#34;&gt;')" mediatype="text/html"/>

But this throws an exception:
======================
2006-12-01 16:29:27,690 ERROR org.orbeon.oxf.webapp.ProcessorService  - Exception at null, line -1, column -1
org.orbeon.oxf.common.ValidationException : null, line -1, column -1: Cannot parse value as text/html for value: '<xhtml:div id="error-context" title="testing">'
null, line -1, column -1: Cannot parse value as text/html for value: '<xhtml:div id="error-context" title="testing">'
        at org.orbeon.oxf.xforms.XFormsUtils.streamHTMLFragment(XFormsUtils.java:505)
        at org.orbeon.oxf.xforms.processor.handlers.XFormsOutputHandler.end(XFormsOutputHandler.java:135)
        at org.orbeon.oxf.xml.ElementHandlerController.endElement (ElementHandlerController.java:176)
        at org.orbeon.oxf.xml.ForwardingContentHandler.endElement(ForwardingContentHandler.java:52)
        at org.orbeon.oxf.xml.ElementFilterContentHandler.endElement(ElementFilterContentHandler.java :54)
        at org.orbeon.oxf.xml.SAXStore.replay(SAXStore.java:173)
        at org.orbeon.oxf.xforms.processor.XFormsToXHTML.outputResponse(XFormsToXHTML.java:381)
...

Has anyone done this succesfully before? Would anyone have an example?

Thanks!

Sincerely,
Henrik Pettersen
Advanced Computation Laboratory
Cancer Research UK

On 10/26/06, Henrik Pettersen <[hidden email]> wrote:

> Erik,
>
> thank you for the long reply! I certainly have a better understanding
> of where the XForms working group is coming from, and what limitations
> they are working against. Indeed, I'm actually quite impressed by what
> the working group has achieved in a relatively short amount of time,
> and the simplicity of the syntax of the XForms specification.
>
> However, I am still not convinved about the method used for rendering
> HTML attributes from instance values (e.g. <img src=""/>), escaping &
> and < characters and using xforms:output. I can see how it would work,
> I'm just not very keen on the syntax.
>
> Now, it's allways easier to criticize than to come up with new ideas,
> and the XForms working group has come a long way. Perhaps someone else
> has any thoughts on this subject, perhaps some ideas?
>
> What about treating image, audio and video as first class citizens of
> the XForms Controls and markup, and let various browser plugins in
> XForms players decide how to play them (XSLT/Javascript in OPSs case)?
>
> <xforms:image>
> <xforms:audio>
> <xforms:video>
>
> Just my 2 cents. My apologies for making this into an XForms
> discussion on this ops-users mailing list :-)
>
> Henrik
>
> On 10/25/06, Erik Bruchez <[hidden email]> wrote:
> > Henrik,
> >
> >  > That's great! But the working group will need to ensure they come up
> >  > with a specification that allow people to render all the @attributes
> >  > associated with the media type, particularly items such as @alt and
> >  > @src (both required by the XHTML spec). For xhtml:img, the allowed
> >  > (and non-deprecated) attributes are src, height, alt, title, ismap,
> >  > longdesc, usemap and width.
> >
> > That's a delicate question, because remember, XForms is not only
> > usable with (X)HTML. XForms is embedded today in other languages like
> > XSL-FO, XFDL, etc.
> >
> > Also, there will be different attributes depending on the
> > mediatype. An image doesn't have the same attributes as an audio file.
> >
> > For xhtml:img, some of the attributes clearly apply to concepts that
> > can be shared between host languages, like @src, @width, and @height,
> > and possibly @alt, @longdesc and @title. Some are strictly tied to
> > (X)HTML, like @ismap, @usemap.
> >
> > This said, @src is handled automatically (when you bind xforms:output
> > to a node of type xs:anyURI, or if you use the @value attribute). We
> > should probably generate @alt, @title and @londesc from the embedded
> > label and/or hint and help (hint and help are currently not allowed on
> > xforms:output in the official XForms 1.0 schema, but that is changed
> > in 1.1).
> >
> > For @width and @height, we could support xxforms:width and
> > xxforms:height (or xhtml:width and xhtml:height). I am not not sure
> > about @usemap and @ismap (especially the latter as it requires <img>
> > being in an <a>).
> >
> >  > As far as I understand from the above quote: " ... the content model
> >  > of the output element is enhanced to allow the specification of a
> >  > mediatype attribute [Henrik: mediatype="text/html"] or a mediatype
> >  > child element [Henrik: what about mediatype child attributes?]" is a
> >  > nescessary but not complete requirement for rendering all media
> >  > attributes. What's your view on this?
> >
> > Right, the @mediatype attribute or child element tells the XForms
> > engine that the data referenced should be handled as that
> > mediatype. It does not have standard provisions, at the moment, to
> > parametrize the rendering of that mediatype. The rationale behind this
> > from the Working Group is that we await implementors' feedback on such
> > topics. In the meanwhile, implementors are allowed to implement
> > extensions to address those features. But the @mediatype attribute is
> > already a big step forward.
> >
> >  > My apologies, I was not aware that the mediatype="text/html" was part
> >  > of the 1.1 spec. How about "The workaround is to use xforms:output
> >  > with [mediatype="text/html"] (an XForms 1.1 improvement, temporarily
> >  > residing in an ops namespace)"
> >
> > It's not in a namespace at the moment. The attribute is just called
> > "mediatype", as it is in XForms 1.1.
> >
> >  > Hmmm.... This is probably not the right forum, but I would have
> >  > liked the XForms working group to pay closer attention to rich media
> >  > delivery as well. These days, audio and video (and flash!)  are used
> >  > as dynamic content extensively on the web (YouTube, etc.) - it would
> >  > be a shame if the XForms spec did not deal with these nicely.
> >
> > Well, HTML doesn't deal with such content nicely at all, yet the web
> > does ok ;-) Remember, with @mediatype="text/html", you can generate
> > any HTML you want from XForms. So you can produce <object> elements,
> > etc. Exactly the same you would produce directly in HTML.
> >
> >  > It's my pesonal opinion that writing urlencoded strings to represent
> >  > html elements is not really a good solution (Servlets, anyone?).
> >
> > They are not urlencoded: you just have to escape "<" and "&". E.g.:
> >
> >    <my-html>&lt;div>This is &lt;bold> text&lt;/div></my-html>
> >
> > We agree that this is not ideal if you write it by hand.
> >
> >  > Let's hope the 1.1 spec will be complete on this issue :-) Gambaru!
> >
> > Based on what I know, that's unlikely, in particular for reasons
> > mentioned above (feedback from implementors is still needed, and there
> > are workaround such as using text/html), and due to the fact that we
> > can't do everything at the same time ;-)
> >
> >  > I see. Does this bug also apply to asynchronous instance updates?
> >  > I'll have to do some more investigation into this bug/workaround, me
> >  > thinks.
> >
> > It occurs everytime the value changes dynamically.
> >
> > Phew, long reply ;-)
> >
> > -Erik
> >
> > --
> > Orbeon - XForms Everywhere:
> > http://www.orbeon.com/blog/
> >
> >
> >
> >

ObjectWeb mailing lists service home page: http://www.objectweb.org/wws