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] > >
