Well, You're not going to like this answer very much but: It seems unnecessarily cruel to burden your users with the wait time of downloading an XSLT transform engine when you could do such processing on your server.
I know it's cool to do XSLT processing on the client, but this app doesn't sound like it's worth punishing your users by asking them to wait while downloading "all that stuff" FWIW, I do this in one app: a report generator that constructs client-side XML, sends it to a server, then gets back HTML. The report generation process is iterative by design. I only want to transfer human-generated content over the wire. This design also gives me history support "for free", as I can cache previous reports on the server and reload them when requested. On 05/28/2009 06:49 PM, Laurent Malvert wrote: > On May 28, 2:34�pm, Laurent Malvert<[email protected]> wrote: > >> Here's what I have: >> - I have a bunch of XML file on a server describing data, and a bunch >> ofXSLfile defining transformations to HTML code. >> - Each XML file contains the reference to its dedicated timesheet (so >> that basically, using a browser to view the XML file will render it >> more or less correctly). >> >> Here's what I want: >> I want the browser's native XSLT processor to apply theXSL >> transformations to the XML file, so that I can inject the resulting >> HTML code within another page. >> >> Here's what I've done: >> So far I am using the RequestBuilder to fetch the XML file, which >> works OK, but of course the response's content is the raw XML file, >> and not the processed result. Which makes sense (I guess, otherwise >> that could be pretty annoying in other cases). >> My question is, how do I, preferably from GWT, have the browser's >> native XSLT processor do its magic and then get the result to inject >> it? >> >> Any ideas or suggestions? >> >> In the meantime, because I didn't find anything to do this so far (but >> I might have missed it in the docs), I was thinking of improting >> ajaxslt-0.8.1 [1] in my GWT module and call it using JSNI, as it seems >> it is powerful enough to process my stylesheets. >> (but I would have to modify both the stylesheets and the XML files to >> remove the declarations, or maybe remove them dynamically) >> Another possibility was to use Johann Burkard's excellent >> "xslt.js" [2] library, which wraps the native XSLT processor of the >> browser, but I would have preferred a more "GWT-only" solution, in >> case there's already one. >> > > Why doesn't my thread show up in the latest discussions? > > Anyway, I tried both solutions with AJAXSLT and xslt.js, and they both > work fine, though I was hoping for something more integrated since I > didn't see much news on the topic since the 2006 and 2007 discussions > on this matter. > If anyone has anything better, please give me a heads up. > > Cheers, > > -- > Laurent Malvert > Analyst Programmer > Macquarie University, NSW 2109, Australia > Office of Institutional Advancement > > p: +61-2-9850-1385 > m: +61-4-1095-7130 > e: [email protected] > w: http://www.comp.mq.edu.au/ > > CRICOS Provider No 00002J > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
