New XInclude processor

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

New XInclude processor

Erik Bruchez
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
Reply | Threaded
Open this post in threaded view
|

Re: New XInclude processor

Colin O'Brien
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
Reply | Threaded
Open this post in threaded view
|

Re: New XInclude processor

Alexander Žaťko
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
Reply | Threaded
Open this post in threaded view
|

Re: New XInclude processor

Colin O'Brien
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
Reply | Threaded
Open this post in threaded view
|

Re: New XInclude processor

Erik Bruchez
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