Subject: RE: alternating tags in a list? From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Fri, 18 Dec 1998 14:56:07 -0500 |
Hi Keith, You said: ASP is not the only web-based server development environment out there. Netscape uses LiveWire (Server-Side JavaScript)...and almost any server can support Java Servlets. Write your LiveWire or Servlet or ASP application to access your relational database. If you wish to leverage XSL you can turn your query results (tables) into an XML document and then run the XML through an XSL processor using a specified stylesheet. Reply: First part of the comment is right and because its a matter of fact we can add also the roughly 20 to 30 products on the market that does the same ting. Nothing more to say here the second part is probably targeted to a light trafic server. If that is the case, nothing to say here. If, at contrario, it is not the case and ww have to do an implementation on a high trafic server, this is a very bad idea. You said: I don't see XSL as a threat to ASP or as competition to ASP. XSL is meant for "styling" an XML document. Its not meant to be a web-based programming environment. I do feel that scripting should be allowed in an xsl stylesheet, but only to access the relevant objects. Relevant objects would include the source tree or result tree. Scripting should also provide some additional computing power such as mathematical expressions which gets back to how this thread ("alternating tags in a list?") started. I feel that the following should be allowed (the "this" keyword references the current "source" element that is being processed, "number" would return the position of the given element): ... <xsl:template match="employee"> <TD> <xsl:process select="name"/> </TD> <xsl:script> if ((number(this) % 2) == 1) return "<![CDATA[</TR><TR>]]>"; else return ""; </xsl:script> </xsl:template> ... I don't think the next example should be allowed, it really has nothing to do with XML or XSL other than using XML elements for specifying my actions, and I think this is what you two are suggesting: ... <xsl:template match="/*"> <xsl:script> var connection = Database.getConnection("ORACLE", "beq-local","myuser","mypass"); var query = "SELECT * FROM exmployees"; var cursor = connection.cursor(query); while (cursor.next()) { write(cursor.name); } </xsl:script> </xsl:template> ... Reply: You point is: let's keep the XSL as a stylesheet language. OK My point is: We have an oportunity here to have the language to be used either on the server or the client. if we can run the second example, _and_ if we have an efficient XSL interpreter, we have then a chance to have a language that could be used on the server _that_ _can_ do the same work as a ASP page (I know you can do that with.... I picked ASP just as an example, replace ASP by the acronym of you choice as long as it does the same task). If we then have such language on the server we may have a chance to have a common server side scripting tool and not be locked in any proprietary solution (said differently, you can _choose_ the best vendor not being locked to only one. Isn't it what a competitive environment should be doesn't it?). So if you use your second example + the fact of being able to use templates you have the same functionality as you get with asp. It is just a little step further and won't scrapt the XML construct _that_ should be enough versatile to allow assembling constructs in a coherent whole. Don't forget that in the _real_ _world_ we even have to connect to mainframes!!! and that a lot of data, especially for e-commerce is resident on SQL servers not being stored in XML document. Maybe, one day a sql request will return a XML document _but_ we are not there yet. In fact, your second example just showed that such link with actual legacy data could be possible within the XSL framework. >From an other point of view, you first example just showed a) an ineficient way to use server resources (if you have a very loaded server you _should_ know of what I am talking about) b) that legacy data access is not part of the answer provided by XSL. thus, to replace ASP (or any other kind of proprietary solution) by XSL, we can imagine a short XML document used as bootstrap to start a XSL script that will construct the right document (or the XSL interpreter on the server could simply consider a phamtom XML document). This is a server side solution. When, evebody on earth will have a client side XSL interpreter, we may envision different scenario. But, this will not append overnight! Why not consider the current state of the Web instead of dreaming of the perfect world. Utopia is fine but there is a here an now that we have to cope with and a process to go from now to then and from here to there. OK for the then and there and a perfect XSL not poluted by the actual state of the art. But what about the here and now?? and how to get there? where are the steps? Or maybe we should let XSL as is and let a manufacturer listen to request made by developers, do a good job at it and give what they want. Then let the others cry to daddy governement that this guy stoled all the toys in town :-)))) Cheers Didier PH Martin mailto:martind@xxxxxxxxxxxxx http://www.netfolder.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: alternating tags in a list?, Keith Visco | Thread | Re: alternating tags in a list?, Guy_Murphy |
RE: Does the XSL processors within , Jonathan Marsh | Date | Re: XLink support in XSL, Simon St.Laurent |
Month |