According to Joshua Chamas:
> > > > Will you be able to emulate the IIS/ASP 'transformNode'
> > > > method that renders html from xml and xsl components?
> > http://www.sci.kun.nl/sigma/Persoonlijk/egonw/xslt/
>
> transformNode & XSLT are not on my short list of TODOs for
> Apache::ASP, though certainly one could be easily made
> available when the other is too!
It looks like the one above is usable if not complete. I don't
think anything exactly follows the standard yet. The idea would
be to get the calling syntax extablished and simple xsl documents
working.
> However, transformNode is not an ASP method per se but a method
> of one of Microsoft's COM XML objects. So far I have stayed away
> from implementing Microsoft's COM objects like the BrowserCap, the
> AdRotator, and the like, and if I did provided an the XML object,
> I would be starting a general perl port of as many Microsoft COM
> objects as I could do.
The difference here is that XSL transformations *should* follow
vendor-independent standards and I'd like to see it available
on as many platforms as possible. A developer here was already
complaining about how the MS sdk for xml has MS-specific
extensions in all the examples.
> What is on my short list is providing a developer interface
> for rendering XML to HTML. Now I have looked at XSLT, and it is
> pretty scary, even if supposedly necessary for some managing large
> document sets. Its purpose does seem a bit orthogonal to the ASP
> style of interleaving code & content, with the first goal being
> simplicity and power, and then maintainability with decomp through
> includes and modules.
It is more geared toward separating data from presentation, although
in theory you can transform data to other data just as well. I think
it will become extemely useful in cases where you have machine
generated data that can be extracted in xml format and you want
to present it a number of customized ways.
> XSLT seems to seriously complicate the XML rendering issue, and
> perhaps unnecessarily? Has it occurred to anyone that XSLT is just
> another programming language, and one that looks like an HTML doc?
Yes, that is exactly the point, aside from being platform and
vendor-independent. Someone who wants to do HTML presentation
now has a language designed for that. Plus using IE5, you
can push the work out to the browser an let it cache or update
the components separately.
> I'll likely wait this out a bit to see how it shapes up, and would
> finally need an Apache::ASP user to require this functionality before
> pursuing it further. Leslie, are you that user ?
Our situation may be a lost cause. The data in question (commodity
trading stuff) lives on an NT box that has a nice native interactive
interface but the web side has been done with a unix mod_perl wrapper
to get the speed (maybe 30 price pages a second at peak times) and
reliability we need. However we provide custom views of this for
brokers and you can't just turn HTML coders loose on production
mod_perl scripts even if you only need a slightly different look.
So, we've added XML output to the NT server and started using XSL
for some of the new variations, so far running under apache jserv.
However since nearly everyone else here is an NT developer, the
push is to put it all in one box, which is probably going to mean
running IIS and MS-asp so we can sell something easier for other
people to manage. However, since I haven't completely sold my
soul to the dark side (and we aren't sure yet how well it will
work...) I'd really like the xsl to be portable, and usable under
mod_perl. I've had some problems with memory use running java
servlets, although I like the load-balancing feature in the
current apache jserv.
Les Mikesell
[EMAIL PROTECTED]
