Subject: Re: Cascading. ( Re: Recursive Template Application ) From: Paul Tchistopolskii <paul@xxxxxxx> Date: Tue, 20 Jun 2000 20:52:40 -0700 |
From: Matt Sergeant > > > What I was saying was that you shouldn't have to specify the > > > stylesheets on any command line or in the querystring. > > > > Why? > > Same reason you should use DOM and not some other invented API. *Very* suspicious point. There are many usecases when it is *much* better not to use DOM, but to use embedded XSLT engine or one of proprietary XML -> Java class mappers. DOM is just yet another API. Democracy is always good. If following your logic, perl should not be developed, but it should be killed before it has been born, sacrificed for the sake of some ANSI-cerfitied thing which existed at that moment. There are APIs which are good for some task and there are APIs which are bad for some tasks. I can't belive that usage of API not suited for some task is in any way smart, even the API is labeled 'standard'. > Note the english in use here: "shouldn't have to". Not at the exclusion of other > options. I'm not saying ( and I was not saying ) that "you should not use cascading". I'm saying that "you are better not to use it, because hardcoded binding is not scalable". > Sure. Absolutely. You're free to do that. But you're missing the reason > I'm doing server side XSLT: eventually I want to deliver direct to the > browser. To do that you have to follow the spec. Lets call this "Point 1". I *have* to? I'm definately missing the reason, or there is again something wrong with my English ( I apologize, if English is the case. I also can apologize in anvance if anything else is the case.) I don't understand how client-side rendering benefits from making server-side rendering 'cascading based'. cat some.xml | aggregate.xsl | expand_widgets.xsl | render2html.xsl send-to-client="true" To me this eventual rendering on the client is just changing the last component in the pipe ( the rest : layering, tuneability e t.c. ) remains the same. > > > (Note that for anyone interested in AxKit put off by this because it > > > doesn't scale well to 1000's of XML files, its all overrideable in various > > > different ways that do scale better) > > > > What do you mean? > I mean it doesn't have to work this way. Oh! That means you are already providing non-standard way of cascading! This is good ;-) Because this slightly contradicts "Point 1" - could you please elaborate a bit more on this 'non-standard' way? ( Something tells me that there is a big chance that users of AxKit will use that *alternative* method of cascading, but not the 'standard way'.) > People with experience in > building large scale systems based on Cocoon 1 will be the first to tell > you that adding <?xml-stylesheet?> PI's to every document is a pain in the > ass. They better to tell it to Cocoon team. I was never thinking or saying that <?xml-stylesheet?> ( or any other PI/road-sign ) based method of binding is the way to go. I'm constantly saying the opposite. ;-) > So AxKit allows you to work however you want to work. It just happens > to default to the <?xml-stylesheet?> way of working. Not yet questioning why did you placed w3c cascading to be a default ( 100% correct step from marketing point of view ) - I'm realy very interested in alternative way used in AxKit ( because, as I said many times, I very much respect your engeneering skills). Mind to elaborate? > > In AxKIt XSLT transformations don't have access to parameters ????? > > They didn't until tonight. Just added that code. Remember that XSLT on > perl is very young, and AxKit is younger still. I'm sorry - I used a bad wording. My goal was to 'protect XSLT', rather than blame AxKit. Because I'm constantly using XSLT with parameters it was just some emotional cry : "What??? I'm using this every day!!!" <aside> It was similiar to my reaction when ANSI killed Borland's *extremely* useful DDVT syntax extension class Window { void MouseCallBack( Event e ) = [ BASE_HERE + EVENT_ID_HERE ]; } ... this ANSII step kinda killed OWL - but that's another sad story.... I have plenty of sad stories ... ;-) </aside> > Please limit your flames. You're using very derogator terms there. I just > said I added that facility. I said above it didn't do it "yet". It does > now. Happy? Yes, I am shameless and happy. With your change, more people will try to write parametrized XSLT stylesheets in AxKit. Then they will start questioning why can't they access persistant sessions from XSLT stylesheet, then they'l start questioning some other things and then they'l finaly download Ux. ;-) More XSLT users who are writing complex XSLT stylesheets are good for Ux. ;-) Thank you, Matt! ;-) > I'm snipping the continued silliness about how <?xml-stylesheet?> is > broken. If you don't want to use that, then don't. Sure. That's what I said ( in the reply to your first letter which started this thread ) : "... or you can used Ux ... ". Then you said that Ux is not standard, but standards are good for us. Then I replied that maybe standards are good, but they hardly work for semi-complex usecases. > I suggest not trying to invent a new syntax though - write a > NOTE for the W3C - ...ghm... I'm ...patient .... ... patient .... OK. > we as developers need standards , not thousands > of different techniques for applying XSLT > styles to XML files. Maybe "you as developers" need standards. "We as developers" need good tools which allow "us" to write some stuff that works and to do it fast, but supporttable. If the software which allows us to write some stuff fast becomes also standard - that's realy cool. Unfortunately that rarely happens. Why that rarely happens - that's the question I can not answer, because I don't know why. > Its getting stupid now with all the different methods > available. It is getting stupid how stupid are the methods... sometimes ... If some universal method could be explained in 1 paragraph - that's not a big deal to read one paragraph, I think. > > Sounds interesting. But if Salbotron is not SAXParser you may > > find that chaining is not as flexible as you would like, ( for > > example, there could be no way to do: > > > > document("axkit:perl-bean1 | transformation.xsl") > > So make your call to document() a http: request, and have it processed > directly with AxKit. Problem solved. Let us see what happens here. 1. http request -> one more fork of http daemon, network connection e t.c. - but that's not a big deal, and because there is a word 'directly' in your solution, maybe you mean some black magic which saves this overhead. 2. document("htp://localhost:/cgi-bin/processor.cgi") - right? processor.cgi should write out the *valid* XML. Any estimate on the overhead here? ( some very much non-optimized ) code below: protected void emitAttrValue(String value) throws SAXException { int valueLength = value.length(); for (int i = 0; i < valueLength; i++) { char c = value.charAt(i); switch (c) { case '\n': emit(" "); break; case '&': emit("&"); break; case '<': emit("<"); break; case '"': emit("""); break; case '\r': emit(" "); break; case '\t': emit("	"); break; default: emit(String.valueOf(c)); } } The similiar thing is with every char in every chunk of *text* in the generated document. case '&': emit("&"); break; case '<': emit("<"); break; case '>': emit(">"); break; 3. Now document ( "htp://localhost:/cgi-bin/processor.cgi" ) should re-parse XML file back. I think one could estimate the overhead of XML parsing. XML parsing is not 'nothing'. It takes some time and... I wish everyone has becnhmarked XML parsers ? Especialy when creating DOM in result of parsing ? After I did that, I implemented clone() method for SQL templates ( XML files of 20-30 lines lenght ). The time savings I got processing one template were comparable to time saving I got not re-opening the JDBC connection and in total with xsl.clone() I got the same code running at least twice as fast. Without re-writes to C. SAX-based Ux approach has no overhead described above. When you use 5-7 pipes to draw some dynamic page, this becomes important. Not yet talking about caching - but that's another story. > Again - lets not invent a new > syntax. Lets hear it for standards. There is some interesting twist with "/! hack". It looks this way because it is probably the *only* possible way to get it working with almost any XSLT processor, not changing too much code of that processor. ( It works with XT not changing a byte in XT code). Passing "some_new:" schema down the road will require changes to / around core Java libraries. <note to="W3C"> Dear w3c. It is me again, the strange hacker who occasionaly turns XSLT into powerful aggregation / scripting framework. I know that you are very busy, developing some serious things which most of us can not understand and use. I heard that at the moment you allowed XSLT implementations to support whatever URIs XSLT implementators want to support. No surprize, most ( if not all ) XSLT implementators are assuming that document( ) will get either URL, or "". I'm wondering, what if some day you may invent some standard URI to invoke pipes of components with document() ? ( I wish you'l not even get to this level, like you ignored the extensions/binding issue, but who knows ... ). If that happens, could you please not place any restrictions on that field before resolving the binding issues in general ? document() and namespace-based java binding are the only hooks to XLST. Anyway binding is processor-specifc ( and will be for a while ) - could you please not restrict the URI in the near future? Thank you, dear W3C, you realy did well with XSLT ! No kidding. </note> Even w3c will produce yet another URI recommendation ( it will take years, I think ;-) and all the XSLT vendors will slowly switch to that recommendation - it will take years again as well. At that point of time my framework will be *much* more than it is now and more likely it will not be based on XT anymore. ;-) But maybe not. Who knows? Rgds.Paul. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Cascading. ( Re: Recursive Temp, Matt Sergeant | Thread | RE: Recursive Template Application, Nacho |
Re: access attribute in the parent , WCB | Date | RE: How is this part of the XSLT sp, Pawson, David |
Month |