On 1/3/06, Werner Punz <[EMAIL PROTECTED]> wrote:
As you checked it out, you must have missed one of the most sophisticated and powerful parts of the toolkit. ;-) The slow loading times you are seeing are almost certainly because you are looking at it in "development mode". In development mode, the toolkit figures out your dependencies and loads them on the fly. This is cool because you don't need to worry about all the indirect needs of your code, and you can more quickly get your own code working. It does, however, result in the slow load times you noticed. (The files _do_ get cached by the browser, though, so that part is not a problem.)
In "production mode", you would either deploy a pre-built Dojo profile or build and deploy your own custom profile. A profile is essentially a definition of which packages you need in your build, and the build system uses the same technique as is used in development mode to determine which code to include in the profile build. The build system produces a single compressed output file, dojo.js, that contains all of the packages you need (and none of the ones you don't), resulting in much, much, much faster load times in production mode.
Defining a custom profile is really simple, and building it is just as simple. Check it out!
--
Martin Cooper
Martin Marinschek wrote:
> In any case we should wait what ADF Faces brings to the table with
> regards to _javascript_, and then see how we merge in the best way.
>
> regards,
>
> Martin
>
Well one thing, I noticed with DOJO after checking it out extensively is
the slow loading times, since it synchronsously loads itself via xmlhttp
request (and probably runs into issues there due to non caching of
_javascript_s within the static browser cache).
As you checked it out, you must have missed one of the most sophisticated and powerful parts of the toolkit. ;-) The slow loading times you are seeing are almost certainly because you are looking at it in "development mode". In development mode, the toolkit figures out your dependencies and loads them on the fly. This is cool because you don't need to worry about all the indirect needs of your code, and you can more quickly get your own code working. It does, however, result in the slow load times you noticed. (The files _do_ get cached by the browser, though, so that part is not a problem.)
In "production mode", you would either deploy a pre-built Dojo profile or build and deploy your own custom profile. A profile is essentially a definition of which packages you need in your build, and the build system uses the same technique as is used in development mode to determine which code to include in the profile build. The build system produces a single compressed output file, dojo.js, that contains all of the packages you need (and none of the ones you don't), resulting in much, much, much faster load times in production mode.
Defining a custom profile is really simple, and building it is just as simple. Check it out!
--
Martin Cooper
This is in my opinion unfortunately a huge showstopper for the otherwise
excellent lib.
Loading times of 20 seconds for a page using dojo are within the normal
timeframe.
Speaking of showstoppers, this is definitely a huge one for dojo, and
almost as big or even bigger than the possible interference problems of
Prototype, because once you enable dojo your pageloading times start to
crawl.
:-(
