[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: alternating tags in a list?
Hi Paul thread 1--------------------------------- Didier PH Martin wrote: > > the problem is with the <action> part. Theorists see no problems but > pragmatist see problems of flexibility. I think that there are two misunderstandings in this part of your post: It isn't theorists versus pragmatists. I'm helping a company with terabyte databases implement a million-hits-per-day XSL delivery system. If that puts me in the "theorists" camp then who is in the pragmatists one? The real distinction seems to between those who value convenience over scalability (reliability, performance, etc.) Flexibility is not at issue: the need for scripting languages on both client and server is absolutely understood by all. I spend most of my life working in a scripting language. The question is whether the scripting language should be a separate layer or the same layer. You seem to agree that it should be a separate layer, so I guess that makes you a "theorist." Reply -------------------------------------- Sorry if you understood this. I didn't meant to call you a theorist. It is only, that the general tone (not necessarily what you said) from people doing stuff calls for such extensions. I don't really know the reasons, but this seems to be a trend. Most arguments against providing access to procedural languages (like ecma script for instance) where invoking putity of design ( an other trend). Ouff, with more training Paul i maybe could become a lawyer :-)) Thread 2 ----------------------------------- > So then, why not have the <action> part defined as a script then? That's what DSSSL does. Reply ------------------------------------- I agree. > You are right, the visitor pattern could be done in each of these languages. > However, if that is done for you, it means less work isn't it ;-) And I > don't see the relationship between Microsoft dependencies and a schema like > suggested ?? thread 3 ---------------------------------- My point is that I am not familiar with any cross-platform technology that allows arbitrary scripting languages to be plugged into any application. Typically, you must either use Windows' Active Scripting stuff, or you must plug in each scripting language to your framework individually. Plugging each language in is probably the same amount of work as implementing the framework in each language. reply ------------------------------------- there is no real multi-OS technology for scripting. However, whatever the reason for, at least for script engines running on Intel provide the same Vtbl interface. Let's call that the facade pattern ;-). So, you can easily re-use these four script engines on Linux if you want as long as you find a way to bind to a vtbl. The limitation to transportability, in that case, is more the CPU type than the OS. demonstration: OS like Linux or Windows provide 'C' binding to librairies or system modules. Just look at function call frames and you'll notice that it is in fact a C function call. Some systems like MacOS are based on a Pascal function call convention. New windows modules provide a C++ vtbl binding (i.e. virtual pure). Some work in progress in the Linux family is around the same C++ VTBL binding. Thus, script languages like Perl or Python could be re-compiled on other CPU type and provide the same vtabl binding. Here you have a transportable schema based on c++ binding instead of c bindings. What wrong with that? Maybe that it wasn't invented in Sun's lab ;-) If we take apart all market share games (or legal games) and just consider what's invested yet. We have at least two public domain script languages having this kind of interface. The third one (free ecmascript) could be easily adapted too. We call that leveraging what's there. Thus, IactiveScript or IActiveScriptParse could be seen as: 1 - C++ interfaces (virtual pure members) 2 - COM/DCOM interfaces 3 - Devil's product :-)))) Let's forget the last two and keep the first one then you may have a platform independant interface. you can do it with GNU. end of demonstration: Thread 3 ---------------------------------- Anyhow, implementing an XSL-like pattern->action pattern is quite logical and should take the pressure off of XSL to be the be-all and end-all replacement for ASP, DOM and everything else. reply --------------------------------------- Right on! XSL is a language with its limits and stength. It seems that it don't provide an good answer to all developers needs. Maybe it is of its basic premises. Anyway, are learning in the process as we learned from DSSSL (and still do). Cheers Didier PH Martin mailto:martind@xxxxxxxxxxxxx http://www.netfolder.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
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
|