<!-- output will then be -->
mod:dog: Bark! I am a dog
mod:cat: Meow! I am a cat
Not quite - that should really be "mod:animal::say-name()" called
twice to be polymorphism - you're calling the "concrete" method
there rather than the abstract.
Uhuh, bad example.... I should actually have a list of mod:animal
which contains both cats and dogs. Then loop the list and call the
fu:say-name() method. Then it would resemble the OO paradigm better.
So why is this polymorphism? Because the common Animal.xslt will
use the $name variable depending on how the transform was
constructed. You call "sayName" in the Animal stylesheet and that
uses the $name variable in the Dog/Cat stylesheet.
I see what you mean and yes, i agree on that it is a (basic form of)
polymorphism.
The Animal stylesheet is kind-of abstract in that it won't run on
it's own because it lacks a declaration for $name.
That is indeed the way I use it now, especially in browser based
XSLT 1.0 (not sure why I encounter it less with XSLT 2.0 on the
server side).
To follow-up on your example using variables, i tend to use the
following construction when I *do* use it with XSLT 2.0 (not avail.
in 1.0). This raises an error when you fail to 'overload' the
variable in your importing stylesheet:
<!-- animal.xslt -->
<xsl:param name="name" required="yes" />
at least you get an error if the dog.xslt or cat.xslt (i.e., the
concrete 'classes' derived from this 'abstract' one) do not specify
the $name parameter. Even better, I use a variable instead as a
'best practice', because the param should not be settable or visible
from the outside (information hiding, haha):
<!-- dog.xslt -->
<xsl:variable name="name" select=" 'dog' " />
Cheers,
-- Abel Braaksma
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--