Hello again CDP,

I've recently jumped into the world of XSLT am discovering the joys
(and nightmares) of using an XSLT translator for making HTML output out
of XML data. Since I'm an utter noobie at this I'm using the Salbatron
translator from within PHP scripts on the webserver.

Salbatron does the trick by from what I read its not a very good
translator for industrial strength apps. But hey, it was pretty easy to
get it up and running which is a big plus in my book right now. I've
also begun to experiment with using the in-browser XSLT translators one
can find in IE and FireFox.

I am wondering if any of the pickies reading this newsgroup are
currently using XSLT translators in a live application envrionment and
what their experiences have been (good or bad) especially in reguards
to the translators performance under production load. I'm also curious
how helpful the translators error output is when the XSLT or XML is
bad. So far, Salbatron sucks in this reguard. The in browser
translators in IE and FireFox are a bit more helpful.

I guess I'm really just trying to get a feel for whats out there for
XSLT translators and which ones are being used by the MV community in
general at the moment.

Many thanks,

Tedd

Tedd Scofield wrote:
I've just recently started using XSLT, but with JSP instead of
PHP/Sablotron, and I like quite well. I could never get PHP/Sablotron
compiled and running on my AIX box.

JSP was the better answer for me because of the above problem, but a
bonus is mo' better error handling.

I use JSP on Tomcat and pull in info from D3 using Christophe Marchal's
org.jd3 stuff. Works pretty well, but the performance is a bit slow for
heavy production use.

--
Bob Little
Graphik Dimensions, Ltd.
High Point, NC

"Tedd Scofield" wrote:
I'll openly admit that from the research I've done into XSLT, XPath,
XQuery, and related versions, diversions, and subversions of the
principles - I'm flat out scared of anything having to do with XSLT.

We seem to have come full circle, from disorganized information to
organized XML to completely irrational procedural methods of
reformatting that XML. I get the basic premise: scan for a pattern,
execute code/script for the nodes that match, repeat as required. But
beyond the most basic needs this starts to get hairy very fast.

The tools for creating XSLT are primitive and highly subject to error,
as well as the processors that operate on the documents with their
vendor-specific nuances. It's just too chaotic for my taste and I
choose to completely avoid the whole thing as much as possible - akin
to giving the ranting 3 year old a "time out" until he decides to
behave.

I'm sure others have a different opinion and I'm probably way off on
this. I'll take some heat for completely avoiding a technology like
this, but as with most research projects, no one in the Pick world is
paying me to use it anyway. I've done a decent amount of reading on
the topic so "take time to get to know it" isn't quite the advice I
need. Any book I read has notes like "this might not work by the time
you read it" - acknowledgement that change in this area is going as
fast as extreme developers can push it.

I'm very interested in the experience of others in this area, and it
will be good to hear how you're progressing Tedd.

T

I too have been leary of these technologies until recently. What has
pushed me over the edge into the XSLT world is its abilty (well, the
translators ability) to sort and redisplay the same chunk o data six
different ways from Sunday along with the addition of XSLT translators
in FireFox and IE. The possiblities of what one can do with that XML
data, such as formatting objects that spit out .pdf's, are icing on the
cake right now.

I tried FOP (Formatting Objects Processor) from the Apache group. Its
open source and Java based.

I installed it on my D3/Linux box and it works fine to generate PDF's
from the command line.

http://xmlgraphics.apache.org/fop/

Just make sure you install the Java packages in Linux first!

I moved the directory to /usr/share

mv fop-0.20.5 /usr/share/fop

then I checked fop.sh to see if all the paths are right. And linked it
to /usr/bin
ln -s /usr/share/fop/fop.sh /usr/bin/fop

Heres how I used it:
fop -xsl stylesheet.xsl -xml productdata.xml -pdf catalog.pdf

Good to hear that JSP handles errors well. That uses SAX doesn't it?
What kind of load can it handle before it starts to slow down? I've
shyed away from JAVA in the past but getting SAX and FOP up and running
may break me of that. I've been avoiding having to setup and mantain
another compiler/interpreter.

I kind of fibbed there when I said it was easy to set up. It actually
took quite a few hours to get all the ./configure settings correct but
thats because I built it using apachetoolbox and had to deal with the
way it does its builds. But thats more inline with what I'm
comfortable with. What kind of issues were you bumpinging into trying
to get PHP/Salbatron to compile?

FOP is something I hope to get into very soon (on the fly PDF's /drool
!) Do you have that system in production with users slamming it?

I tend to share your views on that Tony.. I try to avoid using XSLT wherever
possible - it reminds me of PROC (see other threads for my thoughts on
that!) compared to databasic. It's very very powerful, but somehow I like
to reformat my XML in a nice "proper" program - vb.net for me.

I will conceed that for "dynamic" reformatting of data within web sites,
it's probably well worth learning. I just don't want to!

Regards
Simon
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Tony Gravagno wrote:
I'm gonna have to agree with you on this one, Tony. XQuery is dog
ugly, but isn't scary to me. XSLT as a declarative transformation
language feels like regular expressions taken to some extreme that
could be so hard to read that I would not want to make someone maintain
it. I only have book learning on it and haven't even bothered to try
it because at this point I don't care if it works -- I don't like it
(opinions may change at whim/experience)

I just called it declarative. Hmmm. Somehow I don't even care enough
to figure out if it is more declarative or procedural by some
definition or other, but I think I'm right anyway ;-)

Yes. It seems so logical at the outset and it is only when a real XSLT
document is used to transform something significant that you see that
it looks like it would be a real bite to debug or modify.

Agreed.

It is on my "you probably should care about this" list too, along with
..NET but I don't have a strong reason to move it from there right now.

Hey Tony, I'll give you a dollar if you incorporate XSLT into a
production application in 2006. ;-)

Me too and you won't hear that from me.

yup.

All I said was "I agree" but since we have chosen different technology
approaches in the past, I thought I'd pass it along. Cheers! --dawn

Doesn't the .NET framework use things like XPath and XSLT under the
hood when its doing its magic for the VB tools?