init instance from URL (newbie)

I've got some newbie type questions that have arisen in the course of
evaluating OPS.

First, and as another posted just asked earlier today, is the only
factor used in switching between the old and new XForms processors the
presence/absence of the "xforms" attribute on the page element?

Is the new processor considered usable?  Better to stick with the 2.x
version?   I've been using the code from CVS, fwiw.

Onto a specific question.  Say I want to edit a given document, and I
want to use a URL like /app/edit/12345, where '12345' is a document
ID, to access the form.  that is, a GET to that URL should present the
form.  I find that I can do something like

     <page id='edit'
          matcher='oxf:perl5-matcher'
          path-info='/edit/([0-9]+)'
          default-submission='default-edit-submission.xml'
          model='edit-model.xpl'
          view='edit.xsl'>

      <setvalue ref='/form/id' matcher-group='1'/>
      ...
     </page>

that seems to work, sorta.  but things break down from there.  in the
model pipeline I take the default submission and transform it (via a
data access pipeline) into something containing the current values of
the document, as in:

<xforms:model xmlns:xforms="http://www.w3.org/2002/xforms" >
    <xforms:instance>
        <form>
            <id>5630</id>
            <action/>
            <author>craig</author>
            <summary>this is the summary</summary>
        </form>
    </xforms:instance>
    <xforms:submission method="post"/>
</xforms:model>

but those values don't show up in the rendered HTML form.  and anyhow,
I get the feeling that I'm not approaching this in quite the correct
way, so any general guidance would be welcome as well.

--

joe



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

Joseph Dane wrote:

 > I've got some newbie type questions that have arisen in the course
 > of evaluating OPS.

Great, this is why the beta is there for!

 > First, and as another posted just asked earlier today, is the only
 > factor used in switching between the old and new XForms processors
 > the presence/absence of the "xforms" attribute on the page element?

Yes. In summary:

1. @xforms attribute on a <page> element in the page flow -> XForms
    Classic is used.

2. No @xforms attribute on a <page> element in the page flow, AND at
    least one <xforms:model> element under xhtml:html/xhtml:head ->
    XForms NG.

3. None of the above: no XForms engine is run at all.

 > Is the new processor considered usable?  Better to stick with the
 > 2.x version?  I've been using the code from CVS, fwiw.

The new XForms is fairly stable in the betas, but there is a good
number of bugs and a performance issue during initialization of the
XForms engine that have to be fixed before OPS 3.0 final. Browser
support is also currently limited to IE and Mozilla. Beyond these
issues, you should just play with it and see if the feature set
satisfies your needs. If it does, then I guess it qualifies as
"usable" ;-)

The benefit of the XForms Classic engine, present in 2.8 and earlier
as well, is that it is proven and deployed. The big drawback is that
its XForms support is quite limited compared to the XForms NG engine
found in OPS 3.0, and there is no Ajax support, which means less
responsive user interactions. For these two reasons, we are definitely
pushing the new XForms engine, which is where the future of OPS lies.

 > Onto a specific question.  Say I want to edit a given document, and
 > I want to use a URL like /app/edit/12345, where '12345' is a
 > document ID, to access the form.  that is, a GET to that URL should
 > present the form.  I find that I can do something like

[...]

 > that seems to work, sorta.  but things break down from there.  in
 > the model pipeline I take the default submission and transform it
 > (via a data access pipeline) into something containing the current
 > values of the document, as in:
 >
 > <xforms:model xmlns:xforms="http://www.w3.org/2002/xforms" >
 >     <xforms:instance>
 >         <form>
 >             <id>5630</id>
 >             <action/>
 >             <author>craig</author>
 >             <summary>this is the summary</summary>
 >         </form>
 >     </xforms:instance>
 >     <xforms:submission method="post"/>
 > </xforms:model>
 >
 > but those values don't show up in the rendered HTML form.  and
 > anyhow, I get the feeling that I'm not approaching this in quite the
 > correct way, so any general guidance would be welcome as well.

Check, among several similar examples,
bizdoc2/summary/summary-view.xsl. You will see something like this:

<xforms:instance id="document-infos-instance">
     <xsl:copy-of select="/result"/>
</xforms:instance>

The page view in this case is an XSLT stylesheet, which copies, with
<xsl:copy-of>, the result of the page model pipeline to create an
initial XForms instance document.

In your case, you have to do something similar: in the page view, copy
over the XML document produced by your page model under the
<xhtml:head> element. Since you appear to give to your page model the
task of creating an entire XForms model, you should be able to do this
in your page view:

<xhtml:head>
     <xsl:copy-of select="/*"/>
</xhtml:head>

For this to work, don't forget to make your page view an XSLT page
view, with xsl:version="2.0" on its root element.

Note that you don't have to get the entire XForms model generated by
the page model: you can get an XForms instance only, as most OPS
examples do, or any XML document you want, as long as in the XSLT page
view you copy the appropriate values into an XForms instance.

-Erik



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