Hi Kip and David, Thankyou very much for that help, it was very useful
and clarified some things I was unsure of.
I've tried a number of things but I'm still having difficulty defining a
pipeline outside of the PIs.
I looked at the example Stylechoosers and created one myself but since
they populate the $r->pnotes('preferred_style') I can only seem to be
able to define a single style. I tried putting an arrayref of style
names in there but it barfed. If I want to setup a chain of processors
without using the PIs is there a way of doing it?
My thinking is that I could setup a chain of 'dummy' processors using a
stylechooser which all get caught by a custom provider that determines
the actual stylesheets to apply.
So the pipeline might be something like.. branding
stylesheet/localisation stylesheet/user skin stylesheet
Then the provider chooses which of the relavent styles to apply based on
the current session data or whatever.
Does this route sound possible/reasonable or is this just
overcomplicating something that could be better done another way?
Cheers, Tom
-----Original Message-----
From: Kip Hampton [mailto:[EMAIL PROTECTED]
Sent: 17 June 2004 16:42
To: Tom Howe
Cc: [EMAIL PROTECTED]
Subject: Re: Trying to get my head around Stylesheet Choosing & pipeline
type stuff
Tom Howe wrote:
> Hi good folks of Axkit, I've been using axkit for a couple of years
now
> and am planning to migrate from XPathScript to XSLT. I had to add a
> bunch of features to XPathScript to get it to give me nested
components
> with their own stylesheets and am just planning out how I can do this
> using XSLT.
>
> The trouble I am having is trying to get my head around the Stylesheet
> Choosing mechanisms, in the past I did this outside of Axkit and to be
> honest it was a bit messy so im trying to figure out what the "best"
way
> is.
>
> Firstly, am I right in thinking that the AxStyleChooser only runs once
> per request? (and not at each segment of the pipe)
Correct.
>
> Secondly, can the StyleChooser only provide the name of the style to
use
> and not the actualy stylesheet file to use?
Also correct. StyleChooser Plugins are expected to select the unique
*name* associated with an <AxStyleName> block.
>
> Thirdly, what I would like to do is have some module/code/chooser
> whatever make a decision about which stylesheet to apply whenever an
> XSLT stylesheet needs to be applied.
>
> Ideally I could say something like,
>
> 1. Apply XSP
> 2. Apply XSLT - goes and checks stylechooser for stylesheet to apply
> 3. Apply XSLT - goes and checks stylechooser for stylesheet to apply
> 4. Return to browser
AxKit really doesn't work this way; it presumes that all the styles that
will be appled are know *before* the content is passed into the style
processing chain.
>
> 1. AxProvider finds the correct XSP file
> 2. XSP file is executed
> 3. Common XSLT stylesheet is applied that pulls in other components
> required for the page (menus etc) making one big xml/xhtml doc
> 4. Look/feel XSLT stylesheet(s) are applied
>
> What im trying to work out is how best to handle stage 3 and 4. There
> are plenty of different factors that could determine which
stylesheet(s)
> to use.
> Eg.
> - Printable version
> - Localised Country/Sites
> - ReBranding
> - User Preference
> - Browser/Device dependant
> - Accessibility
Each one of these may be set up as a seperate <AxStyleName> block and
selected at request-time via a StyleChooser module. Remeber that a
StyleChooser (like all AxKit Plugins) have full access to the Apache
request object, so, most of the time you can easily determine the state
that is associated with a given style.
>
> My concern is where best to make the decision as to which
stylesheet(s)
> need to be applied. The default seems to be to list them one after the
> other within your XML file as <?xml-stylesheet PIs. This seems awkward
> because it assumes you know which stylesheets may be applied when you
> create the XML document.
No, xml-stylesheet Processing Instructions are *not* the prefered way to
configure AxKit's styleing rules. named styles and media (used in
conjuntion with StyleChooser and MediaChooser modules and other standard
Apache configuration directives) off far more flexibility.
>
> My two options seem to be either
> A) Find a way to work out which stylesheets to apply and then apply
them
> in the correct order.
> - Can I use StyleChooser for this?
Yes.
> - Is there a funky way to automagically edit the xml enroute to add
> dynamic <?xml-stylesheet.. Pis?
You don't need to; see the styling configuration directives instead.
> B) Apply all possible stylesheets one after the other, checking within
> each stylesheet whether it needs to be applied and passing on anything
> it doesn't recognise. This still means that if I want to change the
> stylesheets to be applied then I have to re-edit every file again.
Again, don't use xml-stylesheet PIs. they are there (at best) for very
simple set-ups and create a real mess for more sophisticated sites.
>
> My feeling is to want to avoid putting the references to the
stylesheet
> files within the XSP/XML files since the data could be useful in many
> situations so all sorts of stylsheets might need to be applied to the
> data. Sometimes circumstances might require modifying the pipeline on
> the fly, adding or removing XSLT processing stages, how would one go
> about this?
You cannot (sanely|easily) alter the stylesheet processing chain once it
starts. While 90% of the time, you don't really need to, this is one
issues we hope to address in AxKit2, if possible.
>
> Is there a definitive set of documentation on stylesheet choosing and
> automating the pipeline? I've read all the tutorials I can find.
Chapter 4 of _XML Publishing with AxKit_ [1] covers all of the gory
details about the stylesheet processing chain and how to (ab)use it.
Cheers,
-kip
[1] http://amazon.com/o/ASIN/0596002165
---------------------------------------------------------------------
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]
