Dear Toby,
Thank you for your help.
Your suggestion is interresting. I'm still mulling it over.
Reading your second post yet another time I believe I understand what
you're saying.
You're suggesting to
- pre-compute all the behaviours of all the matchers that would generate SVG
- make the corresponding outcome available to all matchers through
sitemap parameters.
That's a good idea. If you don't have too many SVG matchers of
course, but that's a fair assumption since they are generated by
various XSLT.
You probably think I'm addicted to Xalan extensions but I believe I
will still need the help of the WildcardHelper to work out to what
matcher the SVG source URI belongs from within the XSLT.
Let me clarify this.
XSLT knows
- the src attribute of the picture
- the wildcards/outcome pairs of the various SVG matchers for the
current user's user agent configuration
(n.b. outcome := 'svg'|'bitmap' - a wildcard/outcome pair :
'easy/*.svg' => 'svg').
It still needs to match one with the other.
Below are more considerations in random order.
Suppose a given document must contain two SVG images :
- first SVG is easy and can be rendered by most browsers.
- second SVG is more sophisticated and will be rasterized for some browsers.
The XML form of the document is sth like
<doc>
<paragraph>
Blah Blah
<figure src="easysvg"/>
Blah Blah
<figure src="complexSVG"/>
Blah Blah
</paragraph>
</doc>
The sitemap has several set of rules depending on the complexity of the SVG :
- The matcher for easySVG for example allows all browsers to render SVG.
- The matcher for complexSVG falls back to raster when the browser
is Firefox (e.g. SVG includes filters, unsupported by FF)
For Firefox, the transformer generating XHTML is supposed to emit
...
<p>Blah Blah</p>
<embed src="easySVG"/>
<p>Blah Blah</p>
<img src="complexSVG"/>
<p>Blah Blah</p>
...
The XSL needs to know what form complexSVG will take so as to generate
an <img> tag, even though easySVG may take another form : <embed>.
In other words SVG() is not simply a function of the browser but of
the browser capabilities as well as the SVG complexity.
Please note that you don't even need these two SVGs to be located in
the same document to run into the problem. It's enough that two
documents are generated by the same XSLT and one includes the easy SVG
whereas the other includes the complex SVG.
And I can have many XSLT matchers and many SVG matchers.
When I write the XSLT I'm not supposed to code the rules again
otherwise that means I need to maintain two copies of [possibly
numerous] rules one in the sitemap and one in the XSL (possibly many
as well, could <xsl:import ... though).
Putting the rules at the matcher level allowed me to have different
rules for different URLs. It's just that they're "hidden" from the
matcher that generates the XHTML document.
Putting them 'above' is OK, I just need the outcome to be visible to
the selectors.
You'll probably argue that a faster strategy would be to tailor the
SVG upstream to avoid 'complexity' for browsers with weak SVG support.
I'm doing that already. Especially because DOMs are relatively different.
Alain Pannetier
P.S. I recall times when I thought XHTML/CSS cross browser
compatibility was hard :-(
On 8/18/06, Toby <[EMAIL PROTECTED]> wrote:
Alain Pannetier wrote:
> Toby wrote:
> > you could put the action around everything, as the first and only
> > child of <map:pipelines> [...] modify it so that it only computes
> > diagramType on the first request of every session, and then it just
> > returns a cached value.
>
> This is actually what I started doing but then it finally dawned on me
> that a given document or a given pattern generating various document
> needs to cater for various types of SVG documents.
I don't understand your point very well.
You say that a document or a pattern needs to cater to various SVG
needs. That's exactly why I suggested passing a parameter to the XSLT.
This is how I think it would work:
- the user opens the browser and goes to your site
- the first HTTP request that gets to Cocoon passes through the action
(like every other request, if the action is put around everything)
- the action does its computation based on the user agent and sets one
or more sitemap parameters. it also stores (caches) those parameters
in the session object.
- the request goes on to the relevant matcher
- if needed, any XSLT transformer (both XHTML- and SVG-producing ones)
can make choices based on the parameters set by the action and passed
to them by the pipeline
- every subsequent request goes through the action, but unless the user
switches browser, or closes and reopens it, the action just reads the
cached parameters from the session object.
I'm sure I'm missing something in your problem description, because this
seems much easier to me than writing a custom Xalan extension!
Toby
--
Signed/encrypted mail welcome. GPG/PGP Key-Id: 0x15C5C2EA
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
