[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Implementing an Blogger-style template using XSLT
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@c... > -----Original Message----- > From: Nathan Young -X (natyoung - Artizen at Cisco) > Sent: Tuesday, February 21, 2006 11:22 AM > To: Peter Hunsberger; publicreg@n... > Cc: xml-dev@l... > Subject: RE: 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@l...' > > 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@c... > > > > > -----Original Message----- > > > From: cavecatem@d... [mailto:cavecatem@d...] > > > Sent: Wednesday, February 01, 2006 7:32 AM > > > To: xsl-list@l... > > > 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@l...> > > > --~-- > > > > > > > .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:. > _.:||:._.: > ||:. > > Nathan Young > CDC Site Dev->Interface Development Team > A: ncy1717 > E: natyoung@c... > > > -----Original Message----- > > From: Peter Hunsberger [mailto:peter.hunsberger@g...] > > Sent: Tuesday, February 21, 2006 6:33 AM > > To: publicreg@n... > > Cc: xml-dev@l... > > Subject: Re: Implementing an Blogger-style template > > using XSLT > > > > On 2/21/06, publicreg@n... > > <publicreg@n...> 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> >
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|