How to avoid xpath's document() function?

["Huber, Daniel" <Da...@TechniDATA.DE>]

Hi,

some of you may have read the thread "No lucene, but "Too many open
files".
Now I really try to avoid the use of the xpath function "document()" in
my XSL transformations at all.

But, my use case is not to include content (or complete sub-trees), but
to use the external documents as a look-up table and then react on the
information retrieved.


A concrete, but simplyfied example would be to generate some HTML
select-boxes and populate the options from another XML file:

<xsl:variable name="phrases"
select="document('phrases.xml')/phrases/chapter[@id =
$chapterID]/field[@name = $fieldName]"/>
<xsl:variable name="currentSelection" select="."/>

<select name="{@id}">
   <xsl:for-each select="$phrases/option">
      <option>
         <xsl:if test="text() = $currentSelection">
            <xsl:attribute name="selected">true</xsl:attribute>
         </xsl:if>
     
         <xsl:value-of select="."/>
      </option>
   </xsl:for-each>
</select>


My first idea was to use the XIncludeTransformer. The problem here is
that the returned information has to be processed dynamically. So I
can't simply include a returned sub-tree unmodified.
(OK, admittedly I could split the stylesheet into two parts, but I still
believe there must be a *nicer* way.)

My second idea was to use aggregation, so i would merge the source XML
and all the XML files needed for looking-up some information while
transforming. So the process would be quite the same, but I could stay
within the same XML file. Despite this I find this approach a bit
clumsy, because eventually I must carry along quite large XML trees just
for asking for some values.

Is there sombody out there, with more elegant ideas?


Regards,

Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: How to avoid xpath's document() function?

[Ralph Goers <Ra...@dslextreme.com>]

At 9/20/2004  06:51 AM, you wrote:


>My first idea was to use the XIncludeTransformer. The problem here is
>that the returned information has to be processed dynamically. So I
>can't simply include a returned sub-tree unmodified.
>(OK, admittedly I could split the stylesheet into two parts, but I still
>believe there must be a *nicer* way.)
>
>My second idea was to use aggregation, so i would merge the source XML
>and all the XML files needed for looking-up some information while
>transforming. So the process would be quite the same, but I could stay
>within the same XML file. Despite this I find this approach a bit
>clumsy, because eventually I must carry along quite large XML trees just
>for asking for some values.
>
>Is there sombody out there, with more elegant ideas?

How about CInclude?




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: How to avoid xpath's document() function?

[Jorg Heymans <jh...@domek.be>]

sorry just skimmed briefly through your email, but :
complicated dynamic widget generation seems more a task for CForms and 
flow no? Or did you reject this approach for a particular reason?

Huber, Daniel wrote:
> Hi,
> 
> some of you may have read the thread "No lucene, but "Too many open
> files".
> Now I really try to avoid the use of the xpath function "document()" in
> my XSL transformations at all.
> 
> But, my use case is not to include content (or complete sub-trees), but
> to use the external documents as a look-up table and then react on the
> information retrieved.
> 
> 
> A concrete, but simplyfied example would be to generate some HTML
> select-boxes and populate the options from another XML file:
> 
> <xsl:variable name="phrases"
> select="document('phrases.xml')/phrases/chapter[@id =
> $chapterID]/field[@name = $fieldName]"/>
> <xsl:variable name="currentSelection" select="."/>
> 
> <select name="{@id}">
>    <xsl:for-each select="$phrases/option">
>       <option>
>          <xsl:if test="text() = $currentSelection">
>             <xsl:attribute name="selected">true</xsl:attribute>
>          </xsl:if>
>      
>          <xsl:value-of select="."/>
>       </option>
>    </xsl:for-each>
> </select>
> 
> 
> My first idea was to use the XIncludeTransformer. The problem here is
> that the returned information has to be processed dynamically. So I
> can't simply include a returned sub-tree unmodified.
> (OK, admittedly I could split the stylesheet into two parts, but I still
> believe there must be a *nicer* way.)
> 
> My second idea was to use aggregation, so i would merge the source XML
> and all the XML files needed for looking-up some information while
> transforming. So the process would be quite the same, but I could stay
> within the same XML file. Despite this I find this approach a bit
> clumsy, because eventually I must carry along quite large XML trees just
> for asking for some values.
> 
> Is there sombody out there, with more elegant ideas?
> 
> 
> Regards,
> 
> Daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org