OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Implementing an Blogger-style template using XSLT

[ Lists Home | Date Index | Thread Index ]

Hi.

The XSL is not complete.  There's a mistake in the xpath in the document
function.  There may be other mistakes as well.  This is simplified
prototype code...  If it does not adequately illustrate the point I can
try to expand on it, let me know!!

----->N



.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:
||:.

Nathan Young
CDC Site Dev->Interface Development Team
A: ncy1717
E: natyoung@cisco.com  

> -----Original Message-----
> From: Nathan Young -X (natyoung - Artizen at Cisco) 
> Sent: Tuesday, February 21, 2006 11:22 AM
> To: Peter Hunsberger; publicreg@nascencetech.com
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Implementing an Blogger-style template 
> using XSLT
> 
> 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>
> > 
> 
> -----------------------------------------------------------------
> 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>
> 




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS