Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [XSL] XSL Browser Integration
![Re: [XSL] XSL Browser Integration](/images/get_stylus.gif) At 05:15 AM 9/16/2007, Alain wrote: I have in mind several use-case where XSL gives you a *BIG *bonus when used client-side compared to other existent technos, but these use-case would be irrelevant if they were an obvious reason why XSL should be mostly server-side... And I don't want to bother you with irrelevant things! My guess is that any such "obvious reason" why XSL should be limited to any single architecture, however defined, would be fairly easy to counter with a simple case making different assumptions about requirements. In my experience, XSLT (given the current state of technology) runs in three types of architecture: 1. Batch
2. Server-side ("thin client")
3. Client ("thick client")Plus, of course, hybrid variants. But examine this and you find the distinction is only meaningful as a representation of a spectrum: at one extreme, processing is asynchronous; that is, its timing is determined by the originator. At the other, timing is determined by the receiver. At one end, resources are allocated by the originator; at the other, by the receiver. "Server" in this sense is a mid-point between "batch" and "client" -- an architecture in which the originator devotes resources in order to respond more dynamically than batch, while still addressing requirements on the client for a particular application profile (e.g., for reaching older browsers). In short, I don't see either/or choices; I see tradeoffs. For simple or lightweight applications, any architecture may work fine, and other considerations such as available resources or opacity/transparency may be the deciding factors. I've seen server-side applications installed simply as a convenient way of implementing a batch solution, by using the server's caching and request handling to manage updates. Conversely, many of the problems related to client-side processing (including client-side processing of Javascript) can be ameliorated using just a touch of server-side sniffing and customizing. (Not that I'm a fan of that sort of duct tape; but it can do the job.) Cheers, Wendell So let's summarize opinions & main reasons: ====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ====================================================================== 
|
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
|
