Subject: RE: What will be the future improvements of XSLT? From: Khun Yee Fung <kyeefung@xxxxxxxxxx> Date: Wed, 15 Sep 1999 15:25:30 -0400 |
Some experience of using XSL with HTML people. This message is not very organized, sorry. I have the enviable task :) of having to supervise 3 HTML (+some Javascript) people to use XSLT over the last 2 months in a project. The major problems for them are the 'weird' scoping of variables, the lack of a looping construct, etc. I don't know about other people's experience but it seems like even HTML people are more comfortable with procedural concepts than functional concepts. The scoping concept they got after a few minutes of explanation (and time for them to cool down :). The lack of a looping construct they can live with since it is hard for them to understand the matching rules as it is. When it is possible to avoid using recursion by using apply-templates with a select attribute, that is always the preferred solution for them. So far, the most difficult problems for me to solve are: 1, Drawing a calendar as a table given only the year and the month. They just refused to use XSL for it and decided to use Javascript. With the book "Calendrical Calculations", this has been solved beautifully (although I will have to engineer a switch from lotus XSL 0.17.4 to 0.18.2 in order to get it work properly). The math expression in XSLT is quite messy with all the floor() and the sign with the DIV operator. It works. 2, Sorting of elements according to some arbitrary comparison rule. For instance, after sorting according to dates, sort the elements according to the list 'PGA', 'LPGA', 'Senior PGA', 'European Tour', in this order. Personally I wish I have the same construct as in Perl where I just define a sort template with syntax like: <xsl:sort select="@tour" comparison="golf-compare"/> and something like <xsl:template name="golf-compare"> <xsl:param name="a"/> <xsl:param name="b"/> <xsl:choose> <xsl:when test="a = 'PGA'"> <xsl:value-of select="$a"/> </xsl:when> <xsl:when test="b = 'PGA'"> <xsl:value-of select="$b"/> </xsl:when> <xsl:when test="a = 'LPGA'"> <xsl:value-of select="$b"/> </xsl:when> <xsl:when test="b = 'LPGA'"> <xsl:value-of select="$b"/> </xsl:when> <xsl:when test="a = 'Senior PGA'"> <xsl:value-of select="$b"/> </xsl:when> <xsl:when test="b = 'Senior PGA'"> <xsl:value-of select="$b"/> </xsl:when> <xsl:otherwise> <xsl:value-of select="$a"/> </xsl:otherwise> </xsl:template> With a top-level variable or some other device, I can actually make this into something more generic for sorting any list of elements according to the order in another list. With the current syntax, I don't know how to do that. Did I miss something here? Is it possible to use keys to do this? I have been pleasantly surprised by the amount of hard questions coming from them. I thought it would be a lot more. But the frustration level has been very high and staying high for a long time. As the work progresses, we are encountering another problem: XSLT is very verbose. And the templates for real-life transformations are very messy, especially since we are converting to HTML without CSS (I am not getting into a discussion about CSS). Attributes for tables are messy and hard to group using attribute groups because all tables are basically different in size and other attributes since they are used for formatting of the pages rather than presentation purposes. So, it is sometimes difficult for me to read the templates and follow the logic. This problem every lisp programmer knows: too many defuns. Although we don't use many named templates and therefore naming is still okay so far, the problem is even harder as most templates are nameless and I must rely on the comments to figure out the function of the templates. It would be nice if templates can somehow be grouped together into a module or something. (Hmmm... may be something like XSLT as decorations on XML Schema of the XML files... That would be easier for me to ensure all elements have been taken care of too.) Ease of maintenance will be one of my criteria to decide whether we will be doing XSL in this scale again. We have a few thousand lines of XSL code (with common code factored out to be xsl:included) and it is growing rapidly. My fingers are firmly crossed. Khun Yee -----Original Message----- From: Sara Mitchell [mailto:smitchel@xxxxxxxxxx] Sent: Wednesday, September 15, 1999 10:25 AM To: xsl-list@xxxxxxxxxxxxxxxx Subject: Re: What will be the future improvements of XSLT? No, you're not weird. I also find XSL far less puzzling than javascript. I personally think that the discussions (or is it controversy?) over whether XSL is 'too difficult' or not depends almost exclusively on what the person's previous background is in. Sara David Carlisle wrote: > > > I think also that somebody who can manage HTML with a little JavaScript, > > even given a small subset a XSL, will surely be puzzled by such a > > declarative language. > > Why should this be? > > I find XSL far far less puzzling than javascript. Am I really weird? > > David > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: What will be the future improve, Chuck White | Thread | Re: What will be the future improve, David Carlisle |
Re: xsl:fo in web browsers, Paul Tchistopolskii | Date | Re: What will be the future improve, Simon St.Laurent |
Month |