Hi Brett -- > I'll assume you are referring to XSL-T and not XSL-FO. I've found > XSL-T to be a great way to do a lot of different things in a standard > way, but for most purposes it is overkill and it tends to a > maintainence headache (I hesitate to say nightmare) in production.
I first heard about XSL-T a little over a year ago. My opinion of it has not changed much, and is somewhat similar to your own. I feel that XSL is yet another scheme for dis-integrating HTML from functionality, but that it does so very poorly for a variety of reasons. My primary complaint is that XSL does not reduce complexity. It actually INCREASES the amount of moving parts for dynamic applications. Instead of a traditional CGI->Template->HTML path, XSL implements a more complicated CGI->XML->XSLT->HTML path. Second, nobody knows XSL. Very few programmers know it, and I've NEVER met a competent designer who knows it. XSL is similar in function to CSS. However, LOTS of people know CSS, including all the top web designers. CSS works great -- there is no need to replace it with something which is unproven. The ONLY upside I can see for XSL-T is a situation where you have 10,000 *static* XML documents on your server. In that situation, XSL-T might be a great way to dynamically format your raw data for HTML output. Of course, you could also use T.J. Mather's excellent "Apache::PageKit" for that task. PageKit uses HTML::Template, which is easy for the best designers to use without a need for special training or programming skill. My bottom line opinion: If you are happy with XML geeks designing your web site, XSL is great. If you want to hire the best DESIGNER to design your website, look elsewhere. XSL-T is a solution in search of a problem, IMHO. That said, TIMTOWTDI! If XSL-T is important for what anybody on the list is doing, I am interested in making your job easier. A CGI::Application::XSL module would be utterly simple to make. > See my other posting about CGI::XMLApplication for more on your actual > question. I'm not sure how it makes sense to have as a subclass since > it is just an output mechanism (is there a > CGI::Application::Template?), but I'm not really familiar with common > usage either. The sub-class modifications would just be to an output handler. In fact, this might be a great use of the newly envisioned cgiapp_preoutput() method. The cgiapp_preoutput() method could expect $body to contain a chunk of XML, and based on some other property, an XSL document could be specified. Maybe the XSL-T process could happen as a part of the cgiapp_preoutput(), so that your app module actually spits out HTML. > This is the entire reason I found CGI::Application and subscribed to > this mailing list (CGI::XMLApplication). CGI::Application is itself > similar to things I've designed (I may have some input when I get the > chance) but I was curious about CGI::XMLApplication, although I > haven't really investigated that yet. I expected CGI::XMLApplication > to be related in some way and was surprised when it was not. I suspect Kip did his own module because didn't know about CGI::Application, or because he thought that the state-management aspect of what he wanted to do was less than it really is. What he's done is basically create a more specialized CGI state-management system. I would definitely be interested in working with Kip to make a CGI::Application::XSL module to replace CGI::XMLApplication. He appears to be an expert on the subject and someone who uses this technology on a daily basis, which would make him better candidate than I to figure out the exact functionality. TTYL, -Jesse- ---- Jesse Erlbaum, CTO Vanguard Media 212.242.5317 x115 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
