Hi Andrew,
Very interesting feedback, I'll add my own experience.
Andrew S Tomlinson wrote:
>
> It's interesting to hear about the broader adoption of XSL in a "Model 3".
> I was (and still am) an enthusiastic adopter of XSL but I'd like to add a
> cautionary
> note and remark that from my experience:
> 1. XSL is non-procedural and although it is incredibly easy to use for
> rudimentary
> operations it rapidly becomes very complex when anything a bit more
> sophisticated is
> required. This applies to both the features of xsl (callable templates,
> attribute sets and so on) and to the XPath syntax for matching node sets.
I agree with you that XSL can become quite complex, but when used for
building HTML user interfaces, I think you might try to keep this
complexity to something manageable. We try to use more HTML thingies,
like css stylesheets... instead of using the "full power" of xsl. We
start from am HTML prototype and then copy/paste the bits of pieces of
the html into the appropriate patterns in the XSL sheet. We don't get an
optimal XSLT and we might not get all the advantages of XSL but we don't
get such complex stylesheets. Anyhow, JSP pages can get very complex for
non technical people (even sometimes for technical people :) ) if you
are not careful with the information you "send" there to be processed.
> 2. lack of data-type support means having to bind in java/javascript
> extension functions e.g. for date formatting
But Java already has data-type support and we are generating the XML
from Java so we format the data prior to sending it to the XSLT to be
processed. The XML document just has the "strings" that have to be shown
in the html interface.
> 3. building XSL files is a radically different proposition to building HTML
> (and by extension JSP). This means that you lose the *division of labour*
> that assigns UI construction to (presumably less *technical*) Web Designers.
> Again I have found this to be the case for anything other than the most
> trivial of cases.
I hope your are not right in this one :) because I want my Web Designers
to learn how to use XML and XSL to produce the HTML interface. I hope
tools will help in this regard even though I have to admit that right
now you go a step backwards compared to what HTML tools can do for you.
And I agree that building HTML is somehow different but I don't agree
that JSP pages are like extended HTML. When you start introducing flow
control (if-else, while, for...) then you get your non-technical web
designers into similar problems as with basic XSL. My point here is that
XSL is already "almost" standardized so you don't have to train your
people with your specific taglib library, which also just works with
JSP. XML/XSL can be also used for other kind of environments so my bet
is that if you have to have your Web Designers learn something, then
teach them the broadest standard.
> 4. lack of "self-documenting" features. It's very difficult to come back to
> an XSL file after a while and figure out what some of it actually does; this
> raises the bar on expectation for clear comments by the author(s). I have
> the same "concerns" with SQL as with XPath but at least in SQL I can perform
> an EXPLAIN PLAN to see how the DBMS engine is interpreting the command. I
> would really like a similar rationalization capability in XPath.
I agree with you here. I wish there were something like javadoc (xsldoc?
xmldoc?) to get some documentation. But you have the same problem with
JSP and with XSLT you win that nobody can't misuse the page and get more
info from the database/ open a connection or some of the dangers of JSP.
They just can play with the data you have chosen to send them through
the XML file.
> Now, on the positive I have found it great for basic forms and the
> formatting of static
> tables but, as indicated above, I rapidly hit a ceiling where the increasing
> complexity
> required for incremental functionality was prohibitive.
Well, we haven't yet hit the ceiling. I admit that with the lack of the
tools it requires some manual work though. However, I've also developed
similar applications with JSP and if I were a Web Designer, I'd rather
play with XML than with JSP. Taglibs might change that, but being able
to create the interface without installing, even seeing , a Java class
in your computer is a plus; THAT is complete separation of the logic and
the UI.
We are building our first complete application with the new system right
now, so I might get to the ceiling in some weeks :). I'll let you know
what happens.
Thank you very much for your feedback,
regards,
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
> How does this compare to others' experiences?
> Regards
> @
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
