[
Lists Home |
Date Index |
Thread Index
]
Hi.
I second the assertion that XSL and XML work great for implementing
lightweight custom templating languages.
My interpretation of what you want to do differs from Terence's. I
think what you want is to have an XML (XHTML + custom namespace)
template marked up with placeholders, and an XML file full of values for
those placeholders. Then an XSL to merge the two.
I think I remember Jenni Tennison even had a name for this as a design
pattern but I can't recall what it was.
In any case, if this is what you want, it's similar to a solution I
posted to the XSL list a while ago for localization. Simplified:
The XHTML templates with placeholders look like this:
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml";
xmlns:ln="http://example.com/ln";> <body>
<ln:translateterm key="greeting"/>, <ln:translateterm
key="appelation"/> give me 100 <ln:translateterm key="currency"/>
</body>
</html>
The XML that holds values for the placeholders looks like this:
<?xml version="1.0"?>
<dictionary>
<translateterm key="greeting">Hey</translateterm>
<translateterm key="appelation">person</translateterm>
<translateterm key="currency">dollars</translateterm>
</dictionary>
The XSL transforms the template and looks like:
<!-- get the values for the placeholders from an external XML file -->
<xsl:param name="dictName" />
<xsl:variable name="dictionary"
select="document($dictName)/dictionary/bundle[@language=$language]"/>
<!-- copy everything through as is -->
<xsl:template match="/ | @* | node()">
<xsl:copy>
<xsl:apply-templates select="@* | node()"/>
</xsl:copy>
</xsl:template>
<!-- except placeholders which get replaced with values -->
<xsl:template match="ln:translateterm">
<xsl:variable name="keyToFind" select="@key"/>
<xsl:value-of
select="$dictionary/translateterm[@key=$keyToFind]"/>
</xsl:template>
------------->Nathan
> -----Original Message-----
> From: Nathan Young -X (natyoung - Artizen at Cisco)
> Sent: Wednesday, February 01, 2006 12:31 PM
> To: 'xsl-list@lists.mulberrytech.com'
> Subject: RE: [xsl] Language-specific output
>
> Hi.
>
> Our systems are all still tied to XSL 1.0 (with no nodeset
> extensions) so I can't use variables the way you do in your example.
>
> Instead we use the document function to get what we call the
> dictionary.
>
> The language specific values are stored in an xml file:
>
> <dictionary>
> <bundle language="english">
> <term key="TTitle">XMP Abstract for the file</term>
> ... other english terms
> </bundle>
> <bundle language="german">
> <term key="TTitle">XMP Steckbrief der Datei</term>
> ... other german terms
> </bundle>
> </dictionary>
>
>
> Then at the top of your XSL:
>
> <xsl:param name="language"/>
> <xsl:variable name="dictionary"
> select="document('path/to/dictionary/xml')/dictionary/bundle[@
> language=$language]"/>
>
> Then to get the values:
>
> <xsl:value-of select="$dictionary/term[@key='TTitle']"/>
>
> Terms of course could have more complex structure as needed.
>
>
> ------------->Nathan
>
>
> .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.
> _.:||:._.:||:.
>
> Nathan Young
> CDC Site Dev->Interface Development Team
> A: ncy1717
> E: natyoung@cisco.com
>
> > -----Original Message-----
> > From: cavecatem@directbox.com [mailto:cavecatem@directbox.com]
> > Sent: Wednesday, February 01, 2006 7:32 AM
> > To: xsl-list@lists.mulberrytech.com
> > Subject: [xsl] Language-specific output
> >
> > Hi all,
> >
> > I'm working on a stylesheet that transforms XMP-data to a
> > nicely layouted HTML file.
> > I'm working with oxygen and saxon8b (i.e. XSLT 2.0).
> > Unfortunately, there is the problem of internationalisation,
> > i.e. we have to be able to create at least a German an
> > English version of the HTML file.
> >
> > I'm still new to practicing my XML/XSLT-skills so my problems
> > might simply arise from lack of practice. I didn't find an
> > answer when looking in the list archive, though.
> >
> > Rather than maintain two language versions of the stylesheet,
> > I thought I could try variables in an external file:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <xsl:stylesheet
> > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version="2.0">
> > <xsl:variable name="TFilename">
> > <a lang="de">Datei: </a>
> > <a lang="en">File: </a>
> > </xsl:variable>
> > <xsl:variable name="TTitle">
> > <a lang="de">XMP Steckbrief der Datei </a>
> > <a lang="en">XMP Abstract for the file </a>
> > </xsl:variable>
> > <xsl:variable name="TExifTitle">
> > <a lang="de">EXIF-Daten</a>
> > <a lang="en">EXIF-Data</a>
> > </xsl:variable>
> > <xsl:variable name="TExposureTime">
> > <a lang="de">Belichtungszeit [s]</a>
> > <a lang="en">Exposure time [s]</a>
> > </xsl:variable>
> >
> > <xsl:variable name="lightsource">
> > <a code="1">
> > <a lang="de">unbekannt</a>
> > <a lang="en">unknown>/a>
> > </a>
> > <a code="1">
> > <a lang="de">Tageslicht</a>
> > <a lang="en">Artificial</a>
> > <a>
> > ...
> > </xsl:variable>
> >
> > So I call the normal variables
> > with <xsl:value-of select="$variablename/a [@lang = $lang] />
> > and the complex ones with
> > with <xsl:value-of select="$variablename/a [@code = $code]/a
> > [@lang = $lang] />
> >
> >
> > It was a bit tricky to get around the xsl:include/xsl:import
> > problem, as the stylesheets are modular and my parser
> > insisted that I have to include/import the external file into
> > all sub-stylesheets which then in turn leads to problems with
> > precedence.
> >
> > Three questions actually:
> >
> > 1. Why does the parser insist on me declaring the variables
> > in each separate stylesheet, when he works on the parent
> > stylesheet where the text variable stylesheet is incuded as a
> > top-level element?
> > The same doesn't happen with <xsl:param name=lang> which is
> > only declared in the top level stylesheet.
> >
> > 2. Someone metionend a while ago that it is better to avoid
> > variables as they create result tree fragments. Is there a
> > better way to do this?
> >
> > 3. The XMP data sometimes contains language-sepcific data in
> > elements of the type lang alt, e.g.
> >
> > <dc:description>
> > <rdf:Alt>
> > <rdf:li xml:lang="x-default">Pferde bei der
> > Bachueberquerung</rdf:li>
> > <rdf:li xml:lang="en">Horses crossing a
> stream</rdf:li>
> > </rdf:Alt>
> >
> > Is there a way to get either my specified language or - if
> > that is not present - the 'language' x-default?
> >
> > The following works but doing this for a lot of elements
> > makes it rather slow.
> > ($lang is passed as a global parameter when saxon is called)
> >
> > <xsl:choose>
> > <xsl:when
> > test="rdf:Description/dc:rights/rdf:Alt/rdf:li/@xml:lang = $lang">
> > <xsl:value-of
> > select="rdf:Description/dc:rights/rdf:Alt/rdf:li[@xml:lang
> = $lang]"/>
> > </xsl:when>
> > <xsl:otherwise>
> > <xsl:value-of
> > select="rdf:Description/dc:rights/rdf:Alt/rdf:li[@xml:lang
> > = 'x-default']"/>
> > </xsl:otherwise>
> > </xsl:choose>
> >
> >
> > Thanks for any suggestions that might help.
> >
> > Regards
> > CJ
> >
> >
> >
> >
> --~------------------------------------------------------------------
> > 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@lists.mulberrytech.com>
> > --~--
> >
.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:
||:.
Nathan Young
CDC Site Dev->Interface Development Team
A: ncy1717
E: natyoung@cisco.com
> -----Original Message-----
> From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
> Sent: Tuesday, February 21, 2006 6:33 AM
> To: publicreg@nascencetech.com
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Implementing an Blogger-style template
> using XSLT
>
> On 2/21/06, publicreg@nascencetech.com
> <publicreg@nascencetech.com> wrote:
> > Hi,
> >
> > I'm trying to implement a Blogger-style templating system
> and would like
> > to get some feedback on whether it's feasible or not. While
> it's true that
> > an XSLT file itself would be a template, some of my users
> are not keen on
> > learning it and I'm trying to strike some middle ground here.
> >
> > The premise is this:
> >
> > The template file would be an extension of XHTML and looks
> like this:
> >
> <snip/> -------------------------
> >
> > Then, the data input would come in the form of an XML
> document that looks
> > like this:
> >
> ><snip/> --------------------------
> >
> >
> > Finally, I'd have an XSLT file that uses the 2 files and
> then translates
> > into XHTML code that I can output to the browser.
> >
> > How, folks? Do you think it's feasible to do this? Would
> appreciate any
> > pointers in the right direction.
>
> I've used essentially this architecture since the days when XSLT was
> still a draft standard. It works very well and with proper design can
> have good performance. (Proper design includes many forms of caching.)
>
> Currently we use Apache Cocoon to drive this which gives us a lot of
> capabilities, many of which we don't really exploit. It's probably at
> least worth looking at. In particular you can exploit pipelines to
> break complex XSLT down into multiple transformations which often
> makes hard XSLT problems a lot easier to code (you don't have to build
> up complex variables and re-parse them for some problems) and you can
> aggregate multiple XML sources to make context sensitive parsing much
> easier.
>
> Depending on your eventual deployment targets (cell phones, print,
> other devices?) you may want to go a little more abstract than XHTML
> for your mark up language. XUL, XFORMS or something proprietary
> perhaps.Among other things you might be able to keep the language
> simpler and easier for the end users; and you can maybe separate the
> presentation details from the markup model.
>
> In our case we use a very abstract model and two main XSLT passes.
> The first creates an abstract combined model from the layout model,
> the data, authorizations and other context dependant things (eg. do
> you need internationalization support?). The output of smashing all
> these things together is still an abstract object model, but one that
> maps pretty directly to output, minus any presentation device specific
> details. Depending on the deployment target a second transformation
> then takes care of the specific presentation details.
>
> I'd note that you should also plan on exploiting the capabilities of
> CSS. Depending on your needs it might be possible to do everything in
> pure XML and CSS in which case things can be a lot simpler.
>
>
> --
> Peter Hunsberger
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
|
