cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alain Pannetier" <alain.m.pannet...@gmail.com>
Subject Parsing sitemap from within XSLT Transformer
Date Thu, 17 Aug 2006 20:31:17 GMT
Dear list,

Problem :

I am in a situation in which I need to know from within an XSLT
transformer what matcher will be selected for a given URL.


Use case :

To address SVG cross browser portability issues from the server side,
I've put a little bit of logic in my sitemap to decide whether a given
SVG URL must be sent as plain SVG or should rather fall back to a
rasterized substitute.

<map:match pattern="**/*somepattern*.svg">
  <map:act type="diagram-format">
    <map:parameter name="svg_rule_1" value="outcome = svg;
MSIE_version >= 4;      ASV_version >= 3.0" />
    <map:parameter name="svg_rule_2" value="outcome = svg;
MSIE_version >= 7.2;    NativeSupport == 1" />
    <map:parameter name="svg_rule_3" value="outcome = svg;
Firefox_version >= 1.0; NativeSupport == 0; ASV_version>=6.0" />
    <map:parameter name="svg_rule_4" value="outcome = svg;
Firefox_version >= 3.0; NativeSupport == 1" />
    <map:parameter name="svg_rule_5" value="outcome = svg;
Gecko_version >= 1.9;   NativeSupport == 1" />
    <map:parameter name="svg_rule_6" value="outcome = svg;
Gecko_version >= 1.7;   NativeSupport == 0; ASV_version >= 6.0" />
    <map:parameter name="svg_rule_7" value="outcome = svg;
Opera_version >= 9.0;   NativeSupport == 1" />
    <map:select type="parameter">
      <map:parameter name="parameter-selector-test" value="{diagramType}"/>
      <map:when test="svg">
        <map:read mime-type="image/svg+xml" src="{../1}/{../2}.svg"/>
      </map:when>
      <map:when test="bitmap">
        <map:generate src="{../1}/{../2}.svg" />
        <map:serialize type="svg2png">
          <parameter name="EXECUTE_ONLOAD" type="boolean" value="true"/>
        </map:serialize>
      </map:when>
      <map:otherwise>
        <map:generate src="xml/dummy.xml" />
        <map:transform src="xslt/message.xslt">
          <map:parameter name="message" value="Unknown diagram type
{diagramType}. Expecting one of 'svg', 'bitmap'." />
        </map:transform>
        <map:serialize type="html"/>
      </map:otherwise>
    </map:select>
  </map:act>
</map:match>

Because I've got different matchers, I can have a different set of
compliance rules for different urls.

So far so good.  In case you wonder the browser info against witch the
rules are tallied comes from an ad-hoc cookie sent by the browser.

The complication comes from the fact that depending on the form of the
image, the containing xhtml page will need to include it in an <img>
tag, an <embed> or an <object> tag.  The output can theoretically
contain SVG from any of the various SVG matchers.  This rules out
simply duplicating the configuration rules : they are different.
I know it actually kind of works to include a PNG in an embed tag but
I'd prefer not to rely on this 'feature' (Nevertheless, that's Plan
C).

For now I'm willing to spend some time to try write a Xalan extension
along the line of

<xs:param name="sitemap"/>

<xsl:template match="picture">
   <xsl:variable name="outcome" select="myExtClass:getOutcome($sitemap,@src)"/>
   <xsl:chose>
      <xsl:when test="$outcome == 'svg'">
         <embed .../>
      </xsl:when>
      <xsl:when test="$outcome == 'bitmap'">
         <img src="{@src}"/>
      </xsl:when>
   </xsl:chose>
</xsl:template>


True, I could probably parse the sitemap, passed as sitemap parameter
and obtained through {contextrealpath:sitemap.xmap}, from within the
XSL as well (Plan B) but a more elegant
solution could also be to create a Xalan java extension by
  - building a TreeProcessor
    <xsl:variable name="processor"
select="java:org.apache.cocoon.components.treeprocessor.TreeProcessor"/>
 - somehow find out what matcher is selected.
That's plan A.

  I know that seems wildly outlandish but OTOH I never cease to be
amazed by cocoon's versatility and I can't be the first pimply nerd to
come across this requirement.
 So that I wouldn't be astounded if someone comes forward and say
"Sure, use such-and-such, we guys do that every day".

Any idea ?

Thx in advance

Alain Pannetier.

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


Mime
View raw message