[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
[xsl] RE:"*NEVER* use for-each" and more evils of xsl:script
Subject: [xsl] RE:"*NEVER* use for-each" and more evils of xsl:script From: Joerg Pietschmann <joerg.pietschmann@xxxxxx> Date: Thu, 01 Mar 2001 15:20:10 +0100 |
Well, some more notes regarding the for-each issue. We got a quick start with XML in the following way: 1. Some Web designers design a megacool HTML page which is used as an example. 2. Someone else (read: me) cleans up the mess the design tools write out as HTML and convert it into an XSLT-file by inserting xsl:value-of and xsl:for-each in the appropriate places 3. String it all together. Voila! Made a prototype in a few hours... The problem is, even very minor changes in the HTML-Layout or in the source XML structure usually cause a rewrite of the stylesheet from scratch. There are better ways to waste time. So i convinced someone else to start writing a stylesheet bottom-up using xsl templates. The first results were anything but megacool, the webdesigners were somewhat dissapointed because the thought their ideas went into the bit bucket, and the stylesheet writer got a habit of constantly muttering threats against me, the W3C, the XSLT-designers, various tool vendors, the management and other entities. However, this approach proved much more robust, and, as a side effect, the resulting HTML is much smaller and renders significantly faster, and users report an improved usability. I think this is related to xsl:script evils. Embedding scripts in XSL is not evil per se, and it will certainly solve a lot of problems. However, if abused it *will* become a maintenance problem, and abuse is easy. I'd bet we will soon see stylesheets which have more code embedded in xsl:script than xsl code, and there will be abominations like <xsl:stylesheet> <xsl:script> // some hundred lines of script code </xsl:script> <xsl:template match="/"> <xsl:value-of select="script:doitall()"/> </xsl:template> </xsl:stylesheet> This and other lists will be swamped with requests for optimisation hints for code involving scripts which would be cleaner, more elegant and much more performant coded in pure XSLT. I know this because i'm teaching parts of web designer courses. Most of the students are shockingly clueless about what they are going to do at the beginning. Then they are force-fed HTML and a procedural language (JavaScript), which is hard enough to grasp for them. When i come to teach them about the wonders of XML and XSL, i have first to talk them out of several DHTML induced misbehaviours ("glitz is more important then content"). Getting them to grasp functional programming style would require another few month of intensive teaching. If xsl:script is available, they will fall back into trained patterns using a procedurall language at the slightest glance of difficulties with pure XSLT, even if this requires much more work and code. Embedded script pose also a long term threat to maintainability even if the script language is reasonably well standardised, because tool vendors usually add "value-enhancing" functionality and market it aggressively. This functionality is often used in the initial hype, but often enough such an enhancement is discontinued after a few versions of the tool because a standardised replacement got into the language, the feature simply proved to be redundant, or the vendor got another idea of value-enhancement and changed the spec. Witness all the problems with SQL in this area. It will be hard enough to deal with extension functions in XSLT, which have the advantage of being easily recognisable because of the separate name space. I can also imagine that debugging and profiling facilities for embedded scripts will be somewhat problematic. Even if they are deemed unecessary for initial development, such facilities are indispensable later in the maintenance phase. Everybody who was assigned to a PL/SQL-project should know what i mean. Having said this, well, the only motive for withholding xsl:script would be to prevent innocent users from shooting themselves. However, as everybody, including, but not limited to, the evil empire, already hand out shotguns, we could legalise shotguns as well. A useful compromise might be to label shotguns as dangerous shotguns: put the script tag in another namespace, say "http://www.w3c.org/2000/XSL/Transform/Script" or ".../ProblematicExtensions". Other potential problematic elements like eval might go there as well. I think splitting XSLT into a core and an some standardised extensions would relax a lot of tensions. BTW xsl:output is not a problematic extension, because the concept of outputting the results to a file is easy to comprehend and orthogonal to the way the stylesheet is processed. Regards J.Pietschmann -- XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] A theoretical question, xml startkabel | Thread | [xsl] divide info in several output, Aniceto López |
[xsl] A theoretical question, mcarrasc mcarrasc | Date | Re: [xsl] Re: FXPath - A comment on, David Rosenborg |
Month |