Completely agree with Martin. Once you "get" XSLT and functional programming in general, XSLT is actually pretty cool. I've deployed an application using XSLT and the aforementioned STXX and it went pretty well. Debugging was really easy, and even the performance was very good. You can even do cool stuff like flip a switch in config and now you send the XML and XSLT to the browser for it to be rendered on the client side, saving server resources and enabling mashups with no extra work.
That said, I probably wouldn't chose pure XSLT again, especially now that similar benefits can be had using the REST plugin. Also, JSP has progressed quite a bit since those days, so with JSP tag files and the EL, it isn't quite the pain it was. Don On 12/3/07, Martin Cooper <[EMAIL PROTECTED]> wrote: > On Dec 2, 2007 6:13 AM, Tom Schneider <[EMAIL PROTECTED]> wrote: > > > Personally, I !!HATE!! writing xsl. I try to avoid it at all costs, but > > maybe others might feel differently. > > > For anyone who has only ever worked with imperative languages, XSLT can be a > complete mystery. It's not the most gentle introduction to functional > programming, either. Once you get your head into the functional way of > thinking, though, it's really not so bad. A lot of people complain about > performance, but that's often the result of writing XSLT code that tries to > be imperative. You really do have to "think XSLT" to get the performance up > to par. > > To me, the biggest downside of XSLT in web apps, and especially in a > framework, is that not enough people understand it, or are willing to take > the time to understand it. That means that there's a high probability that > it will go unmaintained, or, worse, "fixed" by people who don't properly > understand the language. > > (Disclaimer: I am _not_ an expert in XSLT, by any stretch of the > imagination.) > > -- > Martin Cooper > > > > > Is the idea here that the action > > would output XML then let the xsl processor on the client convert it to > > html? If so, would you expect the domain model to be automatically > > serialized to xml, or would there need to be code to do that? Also, > > would we need a new xsl for each screen? I guess I'm having trouble > > understanding exactly how this would work. > > > > Where I work, they used to do XML + XSL -> HTML, but they did it > > server-side. It was terrible from a performance perspective--although > > moving it to the client might work better. I would still be a little > > hesitant to go down this path just because of the war stories I heard. :) > > > > I think I would rather see something more along the lines of > > rails/grails. Have a default template that's automatically used for > > list/edit/delete screens. If you need to diverge from the default, then > > you could generate a real view from the template and start with that. > > Tom > > > > Matt Raible wrote: > > > I just thought of something that might be an easy way to generate > > > XHTML views for the REST Plugin. > > > > > > What if we used XSL on the client-side with the XML views? As far as > > > browser capabilities, I think client-side XSL could be a hidden gem > > > that hasn't been looked at in a while. Of course, it could also be > > > something that doesn't work very well across browsers. > > > > > > Do you guys think it's worth looking into? > > > > > > If it works, .html (or .xhtml) could render HTML views and we could > > > allow users to override the XSL stylesheet. > > > > > > Matt > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
