Re: chunked requires?

We've got some code that builds the require chain info and a servlet  
that fires back mini-builds on demand.  We just pushed it out in our  
release last night.  For an example, go to:
	http://testapp.ning.com/xn/loader? 
require=dojo.widget.*,dojo.html,ning.Bar&prefixes=dojo:src,ning:../ 
ning&have=ning.loader,dojo.lang,dojo.io.IO
For debugging purposes, you can also tack on uncompressed=true
On Ning, we use this both to make efficient bulk requires and to do  
async requires so that background stuff doesn't lock up the browser.   
You can see the simple JS interface for this at:
        http://testapp.ning.com/xn/static/js/ning/loader.js

Using a bit of trickier, you can even get it to build 0.4 packages by  
uploading the source and mucking with the package prefix, e.g.:
	http://testapp.ning.com/xn/loader? 
require=dojo.widget.*&prefixes=dojo:../../../../dojo/trunk/src

If you're interested, I can probably get the go ahead to pass along  
the (somewhat embarrassingly ugly) code.  We have to deal with dojo  
0.3.1, but if you wanted to target just 0.4, then a lot of the Java  
code can be simplified, thanks to the great work you guys have been  
doing to clean up the provide/require stuff.

--Tim

> I'm working on building an XML/JSON file that shows the requires  
> chain. There's no reason we couldn't keep that data up to date in  
> the repository, and write a Dojo module that passed the client's  
> already loaded files, and said what file it wants. You can use the  
> saved require chain to find what needs to be concatenated together,  
> and pipe it back.
>
> -Neil
>
> On Oct 22, 2006, at 11:16 PM, Adam L. Peller wrote:
>
> > Sticking to these principles, nothing done so far in i18n  
> > *requires* a
> > build.  However, for performance reasons, it's a good idea.  Exactly
> > how we choose add / factor the localized resources, like how we  
> > factor
> > the JS code itself in Dojo, is a matter of tradeoffs (namely # of
> > hits) if you're not doing a build.
> >
> > -Adam
> >
> > On 10/22/06, Jesse Kuhnert <jkuhnert@xxxxxxxxx> wrote:
> > > No, unfortunately all of my users are used to semi transparent  
> > > localization.
> > > At least as much as a combination of the jdk & localized  
> > > properties files
> > > can provide. I don't think asking them to do a "build" of  
> > > anything is going
> > > to be an acceptable solution for me to give them.
> > >
> > > Certainly they should/hopefully will eventually build their own  
> > > dojo build
> > > for each specific app - but it has to still be "intuitive-ish"  
> > > without doing
> > > it. Oh well, that's the price I pay for taking such a bold step  
> > > with it. I
> > > don't want it to be a dojo specific concern if it doesn't fit the  
> > > ideal
> > > design of the system on it's own. Know what I mean?
> > >
> > > Also, we may want to stop and ponder what it means if we start to  
> > > move in
> > > the direction of it becoming unheard of to do X or Y in dojo  
> > > without using a
> > > tool. It should stand well on it's own. imho at least..
> > >
> > >
> > >
> > > On 10/22/06, Adam L. Peller <adam@xxxxxxxxxx> wrote:
> > > > Isn't this what the build system is for? :-)
> > > >
> > > > Seriously, though, if you think you could accomplish some sort of
> > > > batching from the client, that's an interesting proposal.
> > > > Lazy-loading might also be accomplished with smaller "chunked"  
> > > builds.
> > > > But I'm not sure I understand why a page like this would not  
> > > have the
> > > > widgets and their dependencies in a pre-built dojo.js.
> > > >
> > > > The localization code does add several new hits unfortunately,  
> > > and as
> > > > we localize more widgets, there will likely be even more hits.
> > > > Localized resources might end up factored out into smaller  
> > > files to
> > > > minimize network traffic, but this too assumes that people are  
> > > doing
> > > > builds for their production.  If this is not a valid  
> > > assumption, we
> > > > should discuss.
> > > >
> > > >
> > > > -Adam
> > > >
> > > > On 10/22/06, Jesse Kuhnert <jkuhnert@xxxxxxxxx> wrote:
> > > > > I haven't actually verified anything but with nothing else  
> > > discernible
> > > to go
> > > > > on I'm going to blame the somewhat sluggish loading of some  
> > > of the dojo
> > > > > stuff I've been working with on the # of require calls made.  
> > > (Compare
> > > the
> > > > > load of http://opencomponentry.com:8080/tacos/ to
> > > > > http://opencomponentry.com:8080/timetracker/ and you
> > > will
> > > > > see what I mean. In theory the timetracker url should be  
> > > faster as it is
> > > > > using the latest code - as of yesterday I believe - whereas  
> > > the tacos
> > > url is
> > > > > on 0.3.1 )
> > > > >
> > > > > I'm planning on hacking together some sort of multi response  
> > > require
> > > > > protocol locally, but as I'm assuming this might prove  
> > > beneficial to
> > > more
> > > > > people I thought I'd throw it out there "just in case". For  
> > > my specific
> > > > > needs I pretty much have complete control over any semantics  
> > > involved in
> > > the
> > > > > protocol as assets are handled by a special service for this  
> > > task
> > > already.
> > > > > (it does all kinds of crazy crap already to make all browsers  
> > > happy with
> > > > > various "quircks" here and there...)
> > > > >
> > > > > The basic idea is of course to replace the 10(or so) separate  
> > > require()
> > > get
> > > > > requests with one single request that returns all 10 as a single
> > > response.
> > > > > (in the right order).
> > > > >
> > > > > Anyone else care about this or should I go it alone? (or are  
> > > there any
> > > other
> > > > > ideas other than brute force trying to create as large a  
> > > dojo.js file as
> > > > > possible? )
> > > > >
> > > > > --
> > > > > Jesse Kuhnert
> > > > > Tapestry/Dojo/(and a dash of TestNG), team member/developer
> > > > >
> > > > > Open source based consulting work centered around
> > > > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > > > > _______________________________________________
> > > > > dojo-contributors mailing list
> > > > > dojo-contributors@xxxxxxxxxxxxxxx
> > > > >
> > > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> > > > >
> > > > >
> > > > >
> > > > _______________________________________________
> > > > dojo-contributors mailing list
> > > > dojo-contributors@xxxxxxxxxxxxxxx
> > > > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Jesse Kuhnert
> > > Tapestry/Dojo/(and a dash of TestNG), team member/developer
> > >
> > > Open source based consulting work centered around
> > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > > _______________________________________________
> > > dojo-contributors mailing list
> > > dojo-contributors@xxxxxxxxxxxxxxx
> > > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors@xxxxxxxxxxxxxxx
> > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors@xxxxxxxxxxxxxxx
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors