You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Matt Raible <ma...@raibledesigns.com> on 2007/12/01 18:39:03 UTC
REST Plugin and auto-generated XHTML Views
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
--
http://raibledesigns.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: REST Plugin and auto-generated XHTML Views
Posted by Don Brown <mr...@twdata.org>.
The problem with working off XML rather than Java is you lose the type
information. In order to build a useful form, for example, you need
to know that the 'age' field is a number or that 'created' is a date.
XStream puts some data type information into the markup, but not
enough to really be useful, and you could argue it doesn't belong
there in the first place.
Don
On 12/2/07, Matt Raible <ma...@raibledesigns.com> 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
>
> --
> http://raibledesigns.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: REST Plugin and auto-generated XHTML Views
Posted by Don Brown <mr...@twdata.org>.
On 12/2/07, Jeromy Evans <je...@blueskyminds.com.au> wrote:
> 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.
You mean something like this?
http://particletree.com/notebook/templates-in-javascript/
I've done some work with Trimpath's Javascript Templates and have been
happy with it.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: REST Plugin and auto-generated XHTML Views
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: REST Plugin and auto-generated XHTML Views
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: REST Plugin and auto-generated XHTML Views
Posted by Don Brown <mr...@twdata.org>.
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 <ma...@apache.org> wrote:
> On Dec 2, 2007 6:13 AM, Tom Schneider <sc...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: REST Plugin and auto-generated XHTML Views
Posted by Martin Cooper <ma...@apache.org>.
On Dec 2, 2007 6:13 AM, Tom Schneider <sc...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: REST Plugin and auto-generated XHTML Views
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Antonio Petrelli wrote:
> 2007/12/2, Tom Schneider <sc...@gmail.com>:
>> Personally, I !!HATE!! writing xsl. I try to avoid it at all costs
>
> +1
> XSLT is horrible, counter-intuitive, verbose and probably useless for webapps.
> In Struts 1, projects like StrutsCX and STXX are failing miserably.
+1... a few years ago I was involved in a project that was 100%
XSLT-based, and that wasn't even client-side processing, which is 100x
worse (performance-wise if nothing else)... it just did some database
queries, constructed some XML from the results and then ran it through a
transformation engine with an appropriate XSLT template to generate the
HTML sent to the client... seemed like a good, flexible idea at the
time, but once it was done we couldn't switch technologies fast
enough... difficult to develop, difficult to maintain and ultimately
nowhere near as flexible as we thought it would be.
I think XSLT still has its place when dealing with systematic
transmissions where there's an XML format mismatch, or when transforming
from say XML to CSV or something like that, which I've done too with
better results, but for a webapp front-end generation system? Not
something I'd be interested ever doing again, whether I had to write the
code or not, that's for sure.
> Antonio
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: REST Plugin and auto-generated XHTML Views
Posted by Antonio Petrelli <an...@gmail.com>.
2007/12/2, Tom Schneider <sc...@gmail.com>:
> Personally, I !!HATE!! writing xsl. I try to avoid it at all costs
+1
XSLT is horrible, counter-intuitive, verbose and probably useless for webapps.
In Struts 1, projects like StrutsCX and STXX are failing miserably.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: REST Plugin and auto-generated XHTML Views
Posted by Tom Schneider <sc...@gmail.com>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org