"Jesse Erlbaum" <[EMAIL PROTECTED]> wrote: >It's mostly hype in my experience. And not even very useful hype, like >Java or PHP, which are actually real things which people might want to >use. > >XSLT seems to be XML geeks' answer to CSS+templating. As if CSS wasn't >very successful, as if the world needed another templating system, XSLT >seems to have been invented to take the creative work of designing web >sites out of the hands of HTML designers, and put it in the hands of >XPath programmers. You know. Programmers who are really good at both >creative design and communicating with human beings. Not. > >Alright, pretty smarmy. But unless you just happen to have thousands of >XML documents sitting around on your hard drive, XSLT is a solution in >search of a problem. Most of my data is in a RDBMS -- not XML. To >enhance the *need* for XSLT, some databases will now return XML. That's >an interesting idea. Instead of using a mature language like >Perl|Java|PHP, let's use something like XSLT to turn my data into a web >page! It's new, shiny, and will solve the problem of TOO MANY people >knowing the other aforementioned languages. D'oh! > >Too cynical? Maybe. The fact that XSLT is still discussed in serious >company just bugs me. ;-)
This is a bit disorganized, but I'm trying to explain why different things have their place, at least in the work I'm doing. I am working on a project with the following simplified pipeline in an MVC environment: TT2 -> HTML::Mason -> AxKit -> Client I use each of these for their strengths. I don't expect each one to do everything I need. We want the people that know our customers the best to be the ones that provide the content for the site. These same people are not programmers. They do not like programming. They don't like being near code for fear they will mess something up. I will let them edit TT2 templates. Since they don't like the Unix editors or CVS, I will provide (initially) a web interface for editing and a revision-controlled repository (Gestinanna::POF::Repository). The templates will produce XML so the author can concentrate on content and not worry about presentation. We want others who understand the processes a customer can understand to be the ones writing the controllers. These are XML documents that define a state machine (StateMachine::Gestinanna) that walk a customer through a process to get something done (and applying the right XSLT can create the documentation for the state machine). But these same documents do not expose the full Perl language or the server in the hope of having one less security hole to worry about. In fact, the applications can usually be prototyped without invoking the model or having any code run on a state/edge transition. Once the process flow is finalized, the model can be tied in. These are run in HTML::Mason and determine which template will be used to produce the XML. The model is written as a set of Perl modules (e.g., Gestinanna::POF). The authors of these modules are trusted, usually the same people that are responsible for system security and operation. They can have full access to the server. The modules provide an OO interface to most business operations controlled by the controller. The XML produced by the template is processed by AxKit to produce HTML, WML, or some other format usable by the customer's client. The other benefit of XSLT is that like content is treated in a consistent manner in the end document. Customers can always expect a particular content type to be in a particular format for a given document type without the person writing the content having to constantly check their work against a style sheet. If the person responsible for the layout and look of the site changes something, only the XSLT and CSS have to be changed. Usually, only the CSS has to be changed unless there are major structural changes to the site. The look and layout of the site is done in Photoshop, not in IE. This allows someone that does know XSLT to go in and make sure the resulting HTML matches for a wide range of browsers what was done in Photoshop. We also tend to stick with the W3C recommendations instead of relying on proprietary features/bugs. Of course, we're also a state institution under certain legal restrictions regarding what we can do on the web. So.... I'm using TT2, HTML::Mason and AxKit to work on a site using XML and XSLT. Each has its role based on personnel constraints that are outside the technical requirements of the project. Even so, it results in a highly customizable application that requires little effort at any particular point. I'm working on throwing SOAP and Jabber into the mix as well. I haven't done any performance tuning yet. The primary focus of the application is security, then maintainability, then usability. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
