Personally, I !!HATE!! writing xsl. I try to avoid it at all costs, but
maybe others might feel differently. 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]