New XInclude processor
Locked
 
Administrator
|
All,
The unstable builds now feature a new XInclude processor which implements a subset of the XInclude 1.0 specification. The processor is documented here: http://www.orbeon.com/ops/doc/processors-xinclude You can use this processor in any XPL file, with the name oxf:xinclude, but it is also automatically used by the PFC (previously the PFC relied on the XML parser for XInclude processing). This is very useful for for static page views with XForms, which can now very easily include an XForms instance complete with initialized data, produced by a page model: <html xmlns:xforms="http://www.w3.org/2002/xforms" xmlns:xi="http://www.w3.org/2001/XInclude-doc" xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Summary</title> <xforms:model> <xforms:instance id="document-infos-instance"> <xi:include href="input:data"/> </xforms:instance> ... </xforms:model> </head> <body> ... </body> </html> With XSLT, the solution is very similar: <html xmlns:xforms="http://www.w3.org/2002/xforms" xmlns="http://www.w3.org/1999/xhtml" xsl:version="2.0"> <head> <title>Summary</title> <xforms:model> <xforms:instance id="document-infos-instance"> <xsl:copy-of select="doc('input:data')/*"/> </xforms:instance> ... </xforms:model> </head> <body> ... </body> </html> XSLT is more powerful, but less efficient at runtime. Other than that, the two approaches are quite similar. There is also documentation about the use of XInclude and XSLT for XForms page view: http://www.orbeon.com/ops/doc/reference-xforms-ng#instance-initialization (Note that this last documentation page is still in the works.) -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 |
|
|
Hi Erik,
sounds great - thanks! I'm wondering of this can be used to answer a problem I was seeing a lot last week. Frequently I want to pass some control information or parameters into a stylesheet. I looked at the documentation on how to do that, but it (importing the real stylesheet etc) seemed to be mostly for static information, indeed just a value, whereas I might have a whole xml object. (at least I tried doing a dynamic example and couldn't get it to work). The only solution I have found has been to aggregate the control and content information, but this seems a lot of overhead? I thought what might be preferable would be to define a second input and be able to access it from within the stylesheet. What I'm thinking of is <p: processor name="oxf:xslt"> <p:input name="config" href="#xsl"/> <p:input name="data" href="#content"/> <p:input name="params" href="#siteparams"/> <p:output name="data" id="pageview"/> </p:input> Would I be too hopeful to think that I can now do that, and have in my stylesheet something like <xsl:variable name="siteparams"> <xi:include href="input:params"/> </xsl:variable> Best regards Colin On Oct 21, 2005, at 2:33 PM, Erik Bruchez wrote: > All, > > The unstable builds now feature a new XInclude processor which > implements a subset of the XInclude 1.0 specification. The processor > is documented here: > > http://www.orbeon.com/ops/doc/processors-xinclude > > You can use this processor in any XPL file, with the name > oxf:xinclude, but it is also automatically used by the PFC (previously > the PFC relied on the XML parser for XInclude processing). This is > very useful for for static page views with XForms, which can now very > easily include an XForms instance complete with initialized data, > produced by a page model: > > <html xmlns:xforms="http://www.w3.org/2002/xforms" > xmlns:xi="http://www.w3.org/2001/XInclude-doc" > xmlns="http://www.w3.org/1999/xhtml"> > <head> > <title>Summary</title> > <xforms:model> > <xforms:instance id="document-infos-instance"> > <xi:include href="input:data"/> > </xforms:instance> > ... > </xforms:model> > </head> > <body> > ... > </body> > </html> > > With XSLT, the solution is very similar: > > <html xmlns:xforms="http://www.w3.org/2002/xforms" > xmlns="http://www.w3.org/1999/xhtml" > xsl:version="2.0"> > <head> > <title>Summary</title> > <xforms:model> > <xforms:instance id="document-infos-instance"> > <xsl:copy-of select="doc('input:data')/*"/> > </xforms:instance> > ... > </xforms:model> > </head> > <body> > ... > </body> > </html> > > XSLT is more powerful, but less efficient at runtime. Other than that, > the two approaches are quite similar. > > There is also documentation about the use of XInclude and XSLT for > XForms page view: > > http://www.orbeon.com/ops/doc/reference-xforms-ng#instance- > initialization > > (Note that this last documentation page is still in the works.) > > -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 -- 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 |
|
|
You can do that today. You can refer to the "non-default" inputs in any
XPath expression like this: doc('input: siteparams') Alex. On Oct 22, 2005, at 12:22 PM, Colin O'Brien wrote: > Hi Erik, > > sounds great - thanks! > > I'm wondering of this can be used to answer a problem I was seeing a > lot last week. > Frequently I want to pass some control information or parameters into > a stylesheet. > I looked at the documentation on how to do that, but it (importing the > real stylesheet etc) seemed to be mostly for static information, > indeed just a value, whereas I might have a whole xml object. > (at least I tried doing a dynamic example and couldn't get it to work). > The only solution I have found has been to aggregate the control and > content information, but this seems a lot of overhead? > > I thought what might be preferable would be to define a second input > and be able to access it from within the stylesheet. > What I'm thinking of is > <p: processor name="oxf:xslt"> > <p:input name="config" href="#xsl"/> > <p:input name="data" href="#content"/> > <p:input name="params" href="#siteparams"/> > <p:output name="data" id="pageview"/> > </p:input> > > Would I be too hopeful to think that I can now do that, and have in my > stylesheet something like > <xsl:variable name="siteparams"> > <xi:include href="input:params"/> > </xsl:variable> > > Best regards > Colin > > On Oct 21, 2005, at 2:33 PM, Erik Bruchez wrote: > >> All, >> >> The unstable builds now feature a new XInclude processor which >> implements a subset of the XInclude 1.0 specification. The processor >> is documented here: >> >> http://www.orbeon.com/ops/doc/processors-xinclude >> >> You can use this processor in any XPL file, with the name >> oxf:xinclude, but it is also automatically used by the PFC (previously >> the PFC relied on the XML parser for XInclude processing). This is >> very useful for for static page views with XForms, which can now very >> easily include an XForms instance complete with initialized data, >> produced by a page model: >> >> <html xmlns:xforms="http://www.w3.org/2002/xforms" >> xmlns:xi="http://www.w3.org/2001/XInclude-doc" >> xmlns="http://www.w3.org/1999/xhtml"> >> <head> >> <title>Summary</title> >> <xforms:model> >> <xforms:instance id="document-infos-instance"> >> <xi:include href="input:data"/> >> </xforms:instance> >> ... >> </xforms:model> >> </head> >> <body> >> ... >> </body> >> </html> >> >> With XSLT, the solution is very similar: >> >> <html xmlns:xforms="http://www.w3.org/2002/xforms" >> xmlns="http://www.w3.org/1999/xhtml" >> xsl:version="2.0"> >> <head> >> <title>Summary</title> >> <xforms:model> >> <xforms:instance id="document-infos-instance"> >> <xsl:copy-of select="doc('input:data')/*"/> >> </xforms:instance> >> ... >> </xforms:model> >> </head> >> <body> >> ... >> </body> >> </html> >> >> XSLT is more powerful, but less efficient at runtime. Other than that, >> the two approaches are quite similar. >> >> There is also documentation about the use of XInclude and XSLT for >> XForms page view: >> >> http://www.orbeon.com/ops/doc/reference-xforms-ng#instance- >> initialization >> >> (Note that this last documentation page is still in the works.) >> >> -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 > -- > 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 -- 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 |
|
|
Hi Alex,
yes, I guessed that from Erik's examples - sad I'd never come across it before. But Erik seemed to be implying that using the new XInclude would be even more efficient, so will that work in my example? (Given that I install the nightly builds most days for use in this current development project). While we are talking efficiency and passing parameters... I am generating/using these parameters within model xpl, and then I need to use the same ones in view xpl Is it more efficient to (noting that some of these parameters will be different for each request/response cycle) * aggregate the parameters and the content on the output of the model * store them in the session during the model and retrieve them in the view * generate them again in the model (presumably by having a common sub-pipeline to do the actual generation) (and assuming they are still in the cache) Thanks for your help Colin On Oct 22, 2005, at 12:43 PM, Alexander Zatko wrote: > You can do that today. You can refer to the "non-default" inputs in > any XPath expression like this: > > doc('input: siteparams') > > Alex. > > > On Oct 22, 2005, at 12:22 PM, Colin O'Brien wrote: > >> Hi Erik, >> >> sounds great - thanks! >> >> I'm wondering of this can be used to answer a problem I was seeing a >> lot last week. >> Frequently I want to pass some control information or parameters into >> a stylesheet. >> I looked at the documentation on how to do that, but it (importing >> the real stylesheet etc) seemed to be mostly for static information, >> indeed just a value, whereas I might have a whole xml object. >> (at least I tried doing a dynamic example and couldn't get it to >> work). >> The only solution I have found has been to aggregate the control and >> content information, but this seems a lot of overhead? >> >> I thought what might be preferable would be to define a second input >> and be able to access it from within the stylesheet. >> What I'm thinking of is >> <p: processor name="oxf:xslt"> >> <p:input name="config" href="#xsl"/> >> <p:input name="data" href="#content"/> >> <p:input name="params" href="#siteparams"/> >> <p:output name="data" id="pageview"/> >> </p:input> >> >> Would I be too hopeful to think that I can now do that, and have in >> my stylesheet something like >> <xsl:variable name="siteparams"> >> <xi:include href="input:params"/> >> </xsl:variable> >> >> Best regards >> Colin >> >> On Oct 21, 2005, at 2:33 PM, Erik Bruchez wrote: >> >>> All, >>> >>> The unstable builds now feature a new XInclude processor which >>> implements a subset of the XInclude 1.0 specification. The processor >>> is documented here: >>> >>> http://www.orbeon.com/ops/doc/processors-xinclude >>> >>> You can use this processor in any XPL file, with the name >>> oxf:xinclude, but it is also automatically used by the PFC >>> (previously >>> the PFC relied on the XML parser for XInclude processing). This is >>> very useful for for static page views with XForms, which can now very >>> easily include an XForms instance complete with initialized data, >>> produced by a page model: >>> >>> <html xmlns:xforms="http://www.w3.org/2002/xforms" >>> xmlns:xi="http://www.w3.org/2001/XInclude-doc" >>> xmlns="http://www.w3.org/1999/xhtml"> >>> <head> >>> <title>Summary</title> >>> <xforms:model> >>> <xforms:instance id="document-infos-instance"> >>> <xi:include href="input:data"/> >>> </xforms:instance> >>> ... >>> </xforms:model> >>> </head> >>> <body> >>> ... >>> </body> >>> </html> >>> >>> With XSLT, the solution is very similar: >>> >>> <html xmlns:xforms="http://www.w3.org/2002/xforms" >>> xmlns="http://www.w3.org/1999/xhtml" >>> xsl:version="2.0"> >>> <head> >>> <title>Summary</title> >>> <xforms:model> >>> <xforms:instance id="document-infos-instance"> >>> <xsl:copy-of select="doc('input:data')/*"/> >>> </xforms:instance> >>> ... >>> </xforms:model> >>> </head> >>> <body> >>> ... >>> </body> >>> </html> >>> >>> XSLT is more powerful, but less efficient at runtime. Other than >>> that, >>> the two approaches are quite similar. >>> >>> There is also documentation about the use of XInclude and XSLT for >>> XForms page view: >>> >>> http://www.orbeon.com/ops/doc/reference-xforms-ng#instance- >>> initialization >>> >>> (Note that this last documentation page is still in the works.) >>> >>> -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 |
|
Administrator
|
Colin,
> yes, I guessed that from Erik's examples - sad I'd never come across it > before. Yes, this is documented here: http://www.orbeon.com/ops/doc/processors-xslt#user-defined > But Erik seemed to be implying that using the new XInclude would be > even more efficient, so will that work in my example? > (Given that I install the nightly builds most days for use in this > current development project). If you just need to include, then give XInclude a try. If you need more power, you can very easily switch to XSLT. > While we are talking efficiency and passing parameters... > I am generating/using these parameters within model xpl, and then I > need to use the same ones in view xpl > Is it more efficient to > (noting that some of these parameters will be different for each > request/response cycle) > * aggregate the parameters and the content on the output of the model 1. This is the suggested pattern in OPS. > * store them in the session during the model and retrieve them in the view 2. You wouldn't store them in the session for sure if they are specific to a particular request, because a session is associated with a user, who may have several windows or tabs open at once. But you could use the request scope instead. This would work too, but it's heavier weight. > * generate them again in the model (presumably by having a common > sub-pipeline to do the actual generation) (and assuming they are still > in the cache) 3. You mean in the view, right? This has the drawback of breaking the model-view architecture, and possibly of slowing down your application since you may be running twice the same code. I would just go with #1 above, unless you really come up with a good reason for #2 or #3 :-) -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 |
«
Return to Orbeon Forms community mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |