| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE faqs PUBLIC "-//APACHE//DTD FAQ V1.0//EN" "../dtd/faq-v10.dtd"> |
| |
| <faqs title="XSLT FAQs"> |
| |
| <faq> |
| <question> |
| How do I tell Cocoon to stop adding carriage-returns during XSL |
| transformation? |
| </question> |
| <answer> |
| <p>The short answer is that this is not a Cocoon issue. You need to |
| read up on XSLT usage. Please see |
| <link href="http://cocoon.apache.org/community/mail-lists.html">other resources for XSLT,</link> |
| specifically, the XSL FAQ and discussion lists. |
| </p> |
| <p>The long answer is that you need to use the XSLT function |
| <code>normalize-space()</code> whenever you want to rely on the content |
| of an xml element. |
| </p> |
| <p>For example, if your application is producing some Javascript code in |
| your HTML output, then you might mistakenly try to use the following |
| construct in your XSL stylesheet: |
| </p> |
| |
| <source><![CDATA[ |
| alert('<xsl:value-of select="message"/>'); |
| ]]></source> |
| |
| <p>which will produce:</p> |
| |
| <source><![CDATA[ |
| alert(' |
| messageValue |
| '); |
| ]]></source> |
| |
| <p>The line-endings in the content of your "<code>message</code>" element will cause javascript errors. Instead, do this: |
| </p> |
| |
| <source><![CDATA[ |
| alert('<xsl:value-of select="normalize-space(message)"/>'); |
| ]]></source> |
| |
| <p>Note that there are many more issues about whitespace handling. Please |
| refer to the relevant XSLT resources rather than clutter up the Cocoon |
| discussion lists. |
| </p> |
| </answer> |
| </faq> |
| |
| <faq> |
| <question> |
| Is (your description here) kind of functionality appropriate for a stylesheet? |
| </question> |
| <answer> |
| <p>When this kind of question arises, ask yourself:</p> |
| <ul> |
| <li>Am I using my stylesheet to address style concerns, or am I programming with it?</li> |
| <li>Could I solve this problem once and for all during Generation?</li> |
| <li>Isn't my problem better solved with a Transformer, since it requires coding?</li> |
| </ul> |
| <p> |
| There is not one, nor only one, answer. In Cocoon, you can accomplish the same thing in a number of different ways. Nonetheless, if your transformation depends on something specific happening during generation, it will be more difficult to reuse your code. |
| </p> |
| <p> |
| Here's a hint. Do all that you possibly can in a Generator. Add only what is absolutely |
| necessary with Transformers. Use stylesheets to change format or style, |
| not to code. This approach will make your system more manageable and reusable because it removes dependencies between components. |
| </p> |
| </answer> |
| </faq> |
| |
| <faq> |
| <question> |
| Can I use the same XSLT processor and still specify different processing options for different |
| pipelines? |
| </question> |
| <answer> |
| <p>For example, I found that PDF processing is faster with Xalan when I turn incremental processing off.</p> |
| <p> |
| Yes. For Cocoon version 2.0.3, check out the following <link href="../snippet/snippet-xslt-options.html" >Cocoon snippet.</link></p> |
| </answer> |
| </faq> |
| |
| <faq> |
| <question> |
| Can I use different XSLT processors when processing different pipelines? |
| </question> |
| <answer> |
| <p> |
| Yes. For Cocoon version 2.0.3, adapt the approach discussed in the following <link href="../snippet/snippet-xslt-options.html" >Cocoon snippet.</link></p> |
| </answer> |
| </faq> |
| |
| <faq> |
| <question> |
| How can I remove namespaces from my xml files? |
| </question> |
| |
| <answer> |
| <p> |
| Sometimes adding xsl:exclude-result-prefixes attributes |
| to the <xsl:stylesheet> or literal result element is not effective |
| in removing all namespace declarations. For example, namespace nodes copied |
| from the source document within <xsl:copy> or <xsl:copy-of> instructions |
| (commonly found in catch-all stylesheet templates) will not be excluded. |
| </p> |
| <p> |
| There are two approaches to this problem. |
| </p> |
| <p> |
| One approach is to add a transformation step in your pipeline (or adjust your final stylesheet) with the following: |
| </p> |
| <source><![CDATA[ |
| <?xml version="1.0" encoding="UTF-8"?> |
| <xsl:stylesheet version="1.0" |
| xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> |
| <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/> |
| <xsl:template match="*"> |
| <!-- remove element prefix (if any) --> |
| <xsl:element name="{local-name()}"> |
| <!-- process attributes --> |
| <xsl:for-each select="@*"> |
| <!-- remove attribute prefix (if any) --> |
| <xsl:attribute name="{local-name()}"> |
| <xsl:value-of select="."/> |
| </xsl:attribute> |
| </xsl:for-each> |
| <xsl:apply-templates/> |
| </xsl:element> |
| </xsl:template> |
| </xsl:stylesheet> |
| ]]></source> |
| <p> |
| Another approach is to extend your serializer component, described <link href="faq-serializers.html#faq-4">here</link>. |
| </p> |
| </answer> |
| </faq> |
| |
| <faq> |
| <question> |
| What's "wrong" with use of the document() function in Cocoon? |
| </question> |
| |
| <answer> |
| <p> |
| Using the document() function for aggregation in Cocoon may break |
| Separation of Concerns (SoC). That is, the designers of Cocoon |
| view inclusion and transformation as different functions, best |
| handled by separate Cocoon components. Treating them |
| separately allows you to achieve performance gains and increases |
| the resusability of your pipelines. |
| </p> |
| <p> |
| Alternatives to the document() in the Cocoon environment include |
| aggregation or the use of a multi-stage transformation using the |
| XInclude Transformer. This involves transforming a list of documents |
| (generated dynamically or statically) by adding xinclude elements which |
| reference (via xpointer) specific document content, and then transforming |
| again via the XInclude Transformer, to obtain the desired result. For an example of this, see this <link href="http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102617106411067&w=2">email.</link> |
| </p> |
| <p> |
| You'll achieve better performance if you aggregate content prior to transformation. |
| This allows you to take full advantage of Cocoon's pipeline caching. In contrast, |
| making dynamic document() calls inside an XSLT within a cached pipeline is problematic. |
| At this time, Cocoon does not recognize changes in documents (called by the document() function) |
| until the requested page expires from cache. |
| </p> |
| <p> |
| Understand that the document() function was designed *before* xinclude |
| with xpointer facilities existed. Had such capabilities been available, |
| perhaps the document() function, which essentially mimics xinclude and xpointer, |
| would have never been added to XSLT. |
| </p> |
| <p> |
| Please note that if you must work with your XML files outside of the |
| Cocoon environment, you may need to use the document() function |
| in order to utilize the limited capabilities of other pipeline engines. |
| This includes engines which are not xinclude-capable or which |
| lack a predefined way to indicate document processing steps. If you |
| are working with legacy code from non-pipelined engines, you may need to use |
| the document() function as well, at least initially. |
| </p> |
| <p> |
| If you do use the document() function in Cocoon, you can still observe SoC by |
| having separate XSLT stylesheets perform inclusion and transformation functions. |
| For example, you can put multiple XSLT transforms in a pipeline and have the |
| first one perform inclusion and the second one perform transformation. However, |
| be mindful of some unresolved caching issues in Cocoon related to the document() function. |
| At this time, Cocoon is unable to check validity of content included via the document() |
| function. In addition, the document() function implemented by Xalan is inefficient. See: |
| http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4257 |
| Until this bug is fixed, consider using Saxon instead for document() function-related parsing |
| needs. |
| </p> |
| <p> |
| For other aggregation/inclusion approaches, please stay tuned for XpathDirectoryGenerator (2.1 scratchpad), |
| as well as Forrest's Libre (currently alpha in the Forrest cvs). |
| </p> |
| </answer> |
| </faq> |
| |
| </faqs> |