I haven't invesitgated 4.1, but surely you can always replace the default 170KB dojo.js with a stripped down one, since dojo provides the possibility of custom builds. If you actually use the dojo functionality, of course, your code will be downloaded piecemeal by dojo, but if you avoid the using much of dojo, you can always use a minimalist cutom dojo.js. I actually think it would be a good idea to provide this in the final release of 4.1, so that it will be possible to specify different versions of dojo.js depending upon the intent of your page. For instance, I run my entire website, even the non-dynamic stuff, out of tapestry, using the shell component as a simple templating system and utilizing the internationalization. It isn't a high traffic site, so I can get away with this, but I sure as hell wouldn't want to be sending down a 170KB dojo.js file on pages which have absolutely no javascript whatsoever on them, nor do I want to deal with having to offload the 'static' pages to some other webserver, since they aren't truly static and I do want internationalization.
--sam On 8/5/06, Beat Hoermann <[EMAIL PROTECTED]> wrote:
Jesse Kuhnert <jkuhnert <at> gmail.com> writes: > You should find that no XmlHttpObject's will be created against your will > unless you specifically set a parameter or call a method that is designed to > do it. (whether directly or as a side effect). Good idea! > The framework does continue to include javascript in your pages, as it has > always done. Of course, I guess nobody wants to miss that! It is just a difference to load a few inline JS-snippets of 50 Bytes or a JS-file of 173 KByte. > The summary between that documented page, and another email written on this > list - is that your thoughts are valid/common, but until someone presents me > with a real "problem" that I can measure and test against I'm not going to > invest the time/effort it would require to write the API around unknown > object environments. Do you mean the portlet thread? Here again: The guy doesn't need the 173 KByte "dojo.js". He just turns it off (or later it won't be automatically loaded anymore). I don't quite understand what you mean with "a real problem" and "unknown object environments". I do not have a concrete setting. Intuitively the new "EventListener" and the new "ResponseBuilder" fit. Eventually, I would like to use them for simple XHR-communication (aka ajax) without being forced to load the dojo-infrastructure. I don't know if this can be accomplished or how Tapestry generally supports me doing XHR without writing dynamic scripts and without using dojo. Sure, you guys have already done a lot of conceptional work on this and it is not a problem for me to wait for a refreshed user doc. My current point is: It is not clear to me why a thin web-app has to load the dojo-infrastructure if it doesn't need dojo. (I showed an example in the response to Bernard.) > I would certainly be all for reducing the total compressed size of the > initial dojo bootstrap file though. No argument here for that :) Some of it > would involve simply including less packages in the default build, some of > it involving other things I've been mulling over in my head for a while. Not of a concern to me: Dojo provides so many valuable things for a web-app, all rectifying the additional loading time. My concern: How can I rectify a 10 sec startup-time for a web-app that doesn't use dojo. Thank's for your answer! It is a pleasure for me to see how things evolve around Tapestry and XHR! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
