I thought I'd just add that I've been thinking along the same line as
Matt, but rather than client-side XSTL I've been desperate for a good
quality javascript templating library.
I use the REST plugin to output json results (serialized via the json
plugin) and html templates and merge them on the client-side.
Client-side xstl could replace the merge process but json to a Template
Context object has been a lower entry point. I'd love to get my hands
on a javascript freemarker template engine rather than client-side xstl,
until at least xslt all it's available in all first-grade browers with
better tooling. My client-side template merging process is shoddy though.
Jeromy Evans wrote:
Don will provide much more insight, but I thought I'd mention that the
REST plugin already automatically serializes the model as XML when an
xml response is requested (xstream).
The client can already choose to apply a transformation to that XML
response as proposed by Matt (albeit there's no doctype/schema in the
xml response). The plugin need not play any further part in this.
The xml response can already be customised via xstream converters.
When an html response is requested that REST plugin already returns
the default/specified view as preferred by Tom.
The only facet that's missing is what to provide when an html response
is requested but there's no corresponding view, in which case a
server-side transformation to html would be valuable.
regards,
Jeromy Evans
Tom Schneider wrote:
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]
---------------------------------------------------------------------
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]
