Selon António Mota <amsmota(_at_)gmail(_dot_)com>:
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.
Well at least regarding bandwith consuming you shouldn't do that on client side
as keeping sending those 10000 lines to each client would have a big overhead.
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 must say that I'm a bit confused there :/
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...
Yeah it's quite enough often.
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?
Oh, I suppose you should use their the Saxon.NET directly from your ASP.NET
code.
Hope my 2 cents helped :)
It sure helps, thanks a lot.
On 9/1/05, Sylvain Hellegouarch <sh(_at_)defuze(_dot_)org> wrote:
Hi,
Selon António Mota <amsmota(_at_)gmail(_dot_)com>:
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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--