Ofcourse your insights are very welcome.

> I suppose that using the XmlHttpRequest to fetch an XSLT document to then
use it
> on client side won't make any difference in the end :)

There are two concrete situations that make me think on moving to
server-side:

1) I have situations where i load a 10000 lines XML just to transform
it into a 500 lines, so i think this is better done on the server so i
can load only the 500 lines needed.

2) I have situations where i invoke a ASP from a XSLT using document()
function passing some info in the URL of the document. However i want
to pass a bunch of nodes to it, like i'll do in a send a POST instead
of a GET.

> I guess due to the lack of correct client side environment
> development (understand lack of Javascript tools...)

I can live with only the Mozilla Javascript Debugger for that...

> Saxon.NET is already a port of Saxon so be sure they'll work the same :)
> But again, as long as your XSLT processor respects the W3 standards you
don't
> have to worry, they'll output the same result.

But my question is, can i invoke the XSLT directly, or do i have to
write some wrapper to it, like a ASP on a IIS or a Servlet on a J2EE
server?

> Hope my 2 cents helped :)

It sure helps, thanks a lot.


On 9/1/05, Sylvain Hellegouarch <sh@xxxxxxxxxx> wrote:
> Hi,
>
> Selon Antsnio Mota <amsmota@xxxxxxxxx>:
>
> > Hi again:
> >
> > After playing around with xsl for some months, only on the client
> > (browser) side, i'm beggining to evaluate the benefits of doing it
> > also on the server side. Since i'm not a expert on this, i'll seek for
> > help to the list. So here are some questions.
>
> I'm not an expert but I'll be happy to give you my 2 cents if you will.
>
> >
> > What are the benefits of server-side transforms? How do i make then?
> > Can i call a xslt directly on the server by xmlhttprequest or do i
> > have to write some server-side component that wraps the xslt? (like a
> > servlet or asp)
>
> I suppose that using the XmlHttpRequest to fetch an XSLT document to then
use it
> on client side won't make any difference in the end :)
>
> The question you ask has the same answer as asking for any other part of
your
> code in fact. Should you do the logic on client or server side? It's hard
to
> find the balance. I guess due to the lack of correct client side
environment
> development (understand lack of Javascript tools...) I still do a lot on
server
> side. Besides browsers handle so differently Javascript (Opera doesn't have
> built-in XSLT support yet) that it makes really hard to ensure the code
won't
> break one way or the other.
>
> XSLT processing can be CPU consuming but with some basic cache you'll
improve
> the situation a lot.
>
> >
> > I want to keep the server-side processing the most platform-indpendent
> > as i can. However the company is using IIS and .Net, so how can i
> > achive this?
>
> When you use XSLT, it is your XSLT documents that matter and that's what
makes
> your application platform and language independant. They'll be processed
the
> same way regardless of which XSLT toolkit you might use.
>
> >
> > What processors can i use? Saxon .Net? Can i eventually port some
> > server-side component that uses Saxon .Net to another platform using,
> > say, Java and Saxon?
>
> Saxon.NET is already a port of Saxon so be sure they'll work the same :)
> But again, as long as your XSLT processor respects the W3 standards you
don't
> have to worry, they'll output the same result.
>
> Note also that Saxon.NET works with Mono so your code will be as portable as
it
> can.
>
> >
> > I have more questions than i can formulate, so i'll stop here, but if
> > someone has experince on such a porting, please let me know some
> > insights.
>
> Hope my 2 cents helped :)
>
> - Sylvain
> >
> > Thanks.
> >
> >
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.