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
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 gent
Antonio Petrelli wrote:
2007/12/2, Tom Schneider <[EMAIL PROTECTED]>:
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..
2007/12/2, Tom Schneider <[EMAIL PROTECTED]>:
> 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
--
On 12/2/07, Jeromy Evans <[EMAIL PROTECTED]> 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/notebo
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 usef
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
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
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
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 als
10 matches
Mail list logo
