can database resources be made passed directly to XSLTServlet?

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

can database resources be made passed directly to XSLTServlet?

ron.vandenbranden
Hi,

I am revisiting an existing webapp I had developed some years ago, and
am checking if the workarounds I had to implement back then are still
the best way to proceed. My application first queries the database with
XQuery scripts, and next visualizes those search results via XSLT
stylesheets executed with the XSLTServlet from a controller. Ideally,
the XSLT stylesheet would have access to some auxiliary data files in
the database to enhance the final display; those files are not strictly
necessary in the query phase.

Yet, as far as I know, it is not possible to access database contents
with the XSLT doc() and collection() functions. I have tried to find
another way to pass those files to the XSLT stylesheet, either via the
$parameters argument of the transform:transform() function
(http://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/transform&location=java:org.exist.xquery.functions.transform.TransformModule#transform.3),
or in a <set-attribute> element in the controller
(http://exist-db.org/exist/apps/doc/urlrewrite.xml#D2.2.10). Yet, both
mechanisms only pass string values for parameters. Hence, when trying to
pass those auxiliary data files, the XSLT stylesheet only sees their
string contents; not the actual documents.

In my application, I had resorted to having the XQuery scripts add those
files to the search result output, so that the XSLT stylesheet later on
has access to both the search results and auxiliary data files. In order
to minimize serialization costs, I had the XQuery script derive a subset
of the data files, relevant to the search results. This works, but feels
uneasy, since this means that display-related code has sneaked into the
XQuery script. Moreover, this additional XQuery processing slows down
the actual search (even for searches that don't need the XSLT
transformation), while I believe the kind of lookups they perform would
be less expensive in XSLT (using <xsl:key/>).

So the question I have tried to work around is still standing: is there
a 'direct' way to pass database files to the XSLTServlet, optimally
without intermediate serialization steps?

Best,

Ron

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: can database resources be made passed directly to XSLTServlet?

Alister Pillow-3
Hi Ron,

A stylesheet run from the controller or via the transform function has access to the database using doc() if the (full) path begins with xmldb:exist://. For example
xmldb:exist:///db/path/to/my.xml

The stylesheet will have access to any controller attributes prefixed with "xslt." - e.g.
<set-attribute name="xslt.my_param" value="xmldb:exist:///db/path/to/resource.xml">

and in the stylesheet root, this can be accessed as a param:
<xsl:param name="my_param" />
and you can use the param like this:
<xsl:variable name="a_resource" select="if (doc-available($my_param)) then doc($my_param) else <missing/>" />

Of course if these are static resources, you can simply access them by using
doc("xmldb:exist:///db/path/to/my.xml")

I hope this answers your question.

Regards,
Alister
       

> On 20 Jan 2016, at 8:14 pm, [hidden email] wrote:
>
> Hi,
>
> I am revisiting an existing webapp I had developed some years ago, and
> am checking if the workarounds I had to implement back then are still
> the best way to proceed. My application first queries the database with
> XQuery scripts, and next visualizes those search results via XSLT
> stylesheets executed with the XSLTServlet from a controller. Ideally,
> the XSLT stylesheet would have access to some auxiliary data files in
> the database to enhance the final display; those files are not strictly
> necessary in the query phase.
>
> Yet, as far as I know, it is not possible to access database contents
> with the XSLT doc() and collection() functions. I have tried to find
> another way to pass those files to the XSLT stylesheet, either via the
> $parameters argument of the transform:transform() function
> (http://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/transform&location=java:org.exist.xquery.functions.transform.TransformModule#transform.3),
> or in a <set-attribute> element in the controller
> (http://exist-db.org/exist/apps/doc/urlrewrite.xml#D2.2.10). Yet, both
> mechanisms only pass string values for parameters. Hence, when trying to
> pass those auxiliary data files, the XSLT stylesheet only sees their
> string contents; not the actual documents.
>
> In my application, I had resorted to having the XQuery scripts add those
> files to the search result output, so that the XSLT stylesheet later on
> has access to both the search results and auxiliary data files. In order
> to minimize serialization costs, I had the XQuery script derive a subset
> of the data files, relevant to the search results. This works, but feels
> uneasy, since this means that display-related code has sneaked into the
> XQuery script. Moreover, this additional XQuery processing slows down
> the actual search (even for searches that don't need the XSLT
> transformation), while I believe the kind of lookups they perform would
> be less expensive in XSLT (using <xsl:key/>).
>
> So the question I have tried to work around is still standing: is there
> a 'direct' way to pass database files to the XSLTServlet, optimally
> without intermediate serialization steps?
>
> Best,
>
> Ron
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Exist-open mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/exist-open


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: can database resources be made available directly to XSLTServlet *deployed in Tomcat*?

ron.vandenbranden
Hi Alister,

Thanks for your help. Your answer has made me aware of a specific
condition I had overlooked: I'm deploying my eXist webapps in Tomcat,
which has a limitation w.r.t. its resolver (I believe it's the first
issue mentioned at
http://exist-db.org/exist/apps/doc/validation.xml#D2.2.10).

I have re-tested in a vanilla eXist build with its embedded Jetty
server, and can confirm that a call to e.g.

   transform:transform(
     <test/>,
     <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
       <xsl:template match="/">
         <xsl:copy-of select="doc('xmldb:exist:///db/apps/eXide/build.xml')"/>
       </xsl:template>
     </xsl:stylesheet>
     , ())

in eXide does work.

Yet, when this is executed in an eXist instance deployed as a Tomcat web
application, following error is thrown:

   exerr:ERROR Exception while transforming node: java.net.MalformedURLException: unknown protocol: xmldb [at line 3, column 1]

So, while realizing this is strictly speaking not an eXist issue, maybe
other users have found good approaches for accessing database resources
in XSLT stylesheets executed within Tomcat?

Another one I could think of is replacing the xmldb:exist:// protocol in
the URL with an HTTP call to that document via the REST servlet:

     http://localhost:8080/exist/rest/db/apps/eXide/build.xml

...but I don't know if this additional HTTP request is the most
efficient/elegant way.

Best,

Ron

On 20/01/2016 11:34, Alister Pillow wrote:

> Hi Ron,
>
> A stylesheet run from the controller or via the transform function has access to the database using doc() if the (full) path begins with xmldb:exist://. For example
> xmldb:exist:///db/path/to/my.xml
>
> The stylesheet will have access to any controller attributes prefixed with "xslt." - e.g.
> <set-attribute name="xslt.my_param" value="xmldb:exist:///db/path/to/resource.xml">
>
> and in the stylesheet root, this can be accessed as a param:
> <xsl:param name="my_param" />
> and you can use the param like this:
> <xsl:variable name="a_resource" select="if (doc-available($my_param)) then doc($my_param) else <missing/>" />
>
> Of course if these are static resources, you can simply access them by using
> doc("xmldb:exist:///db/path/to/my.xml")
>
> I hope this answers your question.
>
> Regards,
> Alister

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open