Bill,
I comment below when needed:
> My understanding of access to the view, xform and model documents of a
> page, is summarized by the following, still questionable, assertions
>
> 1. The xform document is strongly oriented to its presentation role,
> (corresponding to swing models in the java gui architecture).
>
> 2. The page's model document is closely related to the (persistent) source
> of the data retrieved for display (corresponding to the JDBC Result
> object,
> in java's database access architecture).
>
> 3. In XSLT stylesheet processing of an xsl view document,
> a. the 'model' document is mapped as the xslt source document and is
> accessible via xpath in the select= attribute on various xsl elements.
>
> b. The 'xforms' document IS NOT available to XSLT, and can NOT be
> used to control what is generated by XSLT.
This is almost true: you have access to the contents of the XForms
instance through the use of XForms controls, such as xforms:input,
xforms:select, xforms:output, etc.
There is also now (CVS) support for an XForms extension that allows
conditional rendering based on content of the XForms instance.
The XForms instance SHOULD be available with document('oxf:instance'),
but this is not the case at the moment. This could easily be fixed
however. You have access to the XForms instance if you write a view
with XPL instead, in which case you can manually connect the
pipeline's instance input to the XSLT processor.
> 4. In Processing of an xhtml view document (provided, or xsl-generated):
> c. the 'xforms' document content is accessible using xpath in an
> <xform:output>
> element.
And other XForms controls, like in the case the XSLT view.
> d. The 'model' document IS NOT available for presentation by xhtml views.
Correct.
> 5. Because of b and d, above the view can not move data between the
> model and the
> xforms docs, and such data manipulation would not be consistent with
> the MVC
> pattern in any case.
>
> 6. In a pipeline that provides the model document, the page's xforms
> document is
> available as the only input to the pipeline.
>
> e. The instance is defined in the pipeline by:
> <p:param name="instance" type="input"/>
> where 'instance' is a pre-defined identifier for the xforms document.
>
> f. xpointer references to the instance take the form
> "document('oxf:instance')/some-path".
Actually, in XPL, they take the form:
#instance#xpointer(/some/xpath/expression)
Our XPointer support is, BTW, not in line with the latest specs.
> g. The model-producing pipeline can thus move data between the model
> (which it
> creates) and the page's xforms document, using xupdate or xslt.
>
> 7. In an <action> of a <page>:
>
> h. The document produced by pipeline 'some.xpl' on <action ...
> action="some.xpl">
> is accessible in xpointer references of the form:
> "document('oxf:action')some-path"
Actually, this is not XPointer, just an XPath expression accessible in
XUpdate in the page flow. You would have to write, like in XSLT:
document('oxf:action')/some/xpath/expression
document('oxf:action') in XSLT and XUpdate represents the document
node of the 'oxf:action' document. So if you want to access the root
element, for example, you write:
document('oxf:action')/my-root-node
or simply:
document('oxf:action')/*
> i. Within the <result> element of an action:
> i) The originating page's xforms document is availabe
> via xpath expressions of the form "document('oxf:instance')/*".
Yes, this refers to the root element of the source page's XForms
instance.
> ii) The result page's xforms document is available via xpath
> expressions
> of the form "/*"
This refers to the root element of the destination page's XForms
instance, which is currently being updated by the XUpdate code.
> Thus <xupdate:update> elements within a <result> can be used to
> transfer data
> from the originating xform to the result xform.
Correct. XUpdate is here the glue between different pages.
> j. The model documents of the originating and result pages are NOT
> accessible
> within an action.
Correct.
>
> Questions
> ---------
> 1. Are my assertions of what can NOT be done (mostly things I have not
> been able to do so far) correct?
>
> The page's 'xforms' document IS NOT available to an xsl stylesheet view.
Correct in the strictest sense, but it should certainly be and this
can be fixed. I entered the following RFE:
http://sourceforge.net/tracker/index.php?func=detail&aid=1050163&group_id=116683&atid=675663
> The page's 'model' document IS NOT available for presentation by an
> xhtml view.
Correct, and that's probably ok. Use XSLT is you want to access and
format page model data.
> The 'model' documents of the originating and result pages ARE NOT
> accessible within an <action>.
Correct.
> 2. Where can I find docuumentation of the OXF document() function, and
> its arguments?
> 3. Assuming that 'oxf:instance' and 'oxf:action' are uri's pre-defined to a
> oxf-specific implementation of document(), are there any other such
> uri's?
This is not an OXF function, it is an XSLT and XUpdate function. It
usually just takes one argument, which is a string (XSLT actually
support passing a node-set / sequence as the first argument, and
support and optional argument to pass a base URI). For example:
document("file:/my-file.xml")
This returns the document node of the given file.
Now Presentation Server supports special URIs of the form:
"oxf:instance"
"oxf:action"
Such forms allow referring to additional pipeline inputs from the XSLT
and XUpdate processors. For example, if a processor is declared as
follows:
<p:processor name="oxf:xslt">
<p:input name="config" href="..."/>
<p:input name="data" href="..."/>
<p:output name="data" id="..."/>
</p:processor>
You can add optional inputs, for example:
<p:processor name="oxf:xslt">
<p:input name="config" href="..."/>
<p:input name="data" href="..."/>
<p:input name="instance" href="..."/>
<p:output name="data" id="..."/>
</p:processor>
The "instance" input can then be referred to, from within the XSLT
stylesheet, using the document('oxf:instance') construct. Same for
XUpdate.
I realize this is missing from the documentation. I have created the
following bugs to track this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1050159&group_id=116683&atid=675660
http://sourceforge.net/tracker/index.php?func=detail&aid=1050161&group_id=116683&atid=675660
It has been suggested, BTW, to use a syntax like "input:action",
"input:instance" or "input:my-input" to make it clearer than the URI
refers to a processor input.
> 5. For debugging purposes, is there a way to display the structure of
> the instance
> document from xhtml, like the following xsl code does for the
> structure of the model
> document?
> f:xml-source>
> <xsl:copy-of select="/*"/>
> </f:xml-source>
No, currently you cannot debug this way. One way, heaver, is to
encapsulate in an XPL file the XHTML or XSLT file, and put XPL debug
attributes in the pipeline.
-Erik
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
orbeon-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
