There is also a Shale proposal{1] related to some of this. Sean
[1] http://www.mail-archive.com/dev@struts.apache.org/msg16683.html On 1/5/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > Sorry for the delay. See below... > > On 1/3/06, Werner Punz <[EMAIL PROTECTED]> wrote: > > Actually this all or nothing or common ground approach is not what I had > > in mind. > > > > What I am thinking of is something along these lines. > > You already have some kind of dynamic loading infrastructure in there > > with > > > > dojo.require("dojo.a"); > > dojo.require("dojo.b"); > > > > now the problem as discussed is that this triggers > > xmlhttp requests and is slow > > > > the alternate solution to this dynamic linking is a static linking via > > an ant build to drop everything into a single file. > > > > Also bad, because one time you download a single huge file (well > > compresset but still) > > This isn't as bad as you think. You do get one large-ish (not huge ;) > download, but you save because of only one request to get it, and the > browser will cache it, so it really is only one download. > > Admittedly, there is a little more pain when using this with JSF because > the JavaScript will be evaluated on each page load, and JSF is still > fundamentally page-oriented. There's not much I can do about that. ;-) > > > This is a viable approach for a webapp but not for a component library > > where one component needs part a of dojo and part b and another one > > needs part a and c. > > > > The infrastructure is there to make dynamic includes upon the given > > needs of the components currently used. > > > > So theoretically if only one component is loaded than an include of part > > a and b is done. > > > > If the second one is added an additional one for part c also is done. > > > > It is sort of a semi dynamic linking where myfaces adds the needed > > includes and neither the build system nor the javascript runtime. > > When you refer to "needed includes" here, what do you mean? Are you talking > about dynamically adding <script src="..."> elements to the page, so that > the browser then fetches them? If so, then I would be _extremely_ surprised > if there's any noticeable performance difference between that and what Dojo > is doing for you, since it ultimately boils down to the same thing. > > If that's not what you mean, then I'm afraid I still don't get it. ;-( > However, from what Adam said, it sounds like ADF Faces will provide it if > Dojo doesn't, so you should be all set. > > -- > Martin Cooper > > > > > You get the benefits of both approaches that way, less code download > > because only the parts needed are loaded and still excellent browser > > caching, due to standard javascript includes. > > > > So my question, does dojo already support such an approach? > > > > Werner > > > > > > > > > > > > > > > > Martin Cooper wrote: > > > I'm not 100% sure I understand what you're looking for, since I'm not > > > completely familiar with the way MyFaces components do things today. But > > > here are a few thoughts: > > > > > > 1) If you're going to use Dojo, I would suggest that you either use the > > > "kitchen sink" profile (that includes everything) or one that includes > > > what all of the widgets in your library need, rather than trying to load > > > only what each widget needs. While that would result in a larger dojo.js > > > file than each widget might need by itself, it means that you get a > > > one-time download to the browser that is then cached, ultimately leading > > > to better performance for the page as a whole. > > > > > > 2) If you render code on the fly that has something like > > > 'dojo.require ("foo")', then Dojo will request "foo" and any > dependencies > > > of "foo", as it would in development mode, but only if they're not > > > already loaded into the browser (e.g. through the profile build). While > > > this isn't what you want as a general solution, it does ensure that your > > > code doesn't break if something got left out of the profile build. Also > > > note that "foo" need not be part of Dojo itself, so you can use Dojo to > > > load your own code too. > > > > > > 3) In theory (meaning, I don't know if anyone has tried it ;), you could > > > generate profile builds on the fly that include only the pieces you > > > need. This sounds cool, but it's not really practical in the long > > > run.The problem is that each custom on-the-fly would be a separate > > > entity as far as the browser is concerned, so you'd be downloading it > > > every time and it wouldn't be cached. Using the approach in #1 is a > > > better way of handling this. > > > > > > Did I answer your question? I'm not sure. If not, let me know what I'm > > > missing, and I'll try again. ;-) > > > > > > -- > > > Martin Cooper > > > > > > > > > On 1/3/06, *Werner Punz* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > > > wrote: > > > > > > Hi Martin, thanks for the clarification, > > > but one question, given that myfaces has its own > > > loading mechanism which renders the includes dynamically. > > > Does dojo have something which could support this. > > > The reason why I am asking is, that > > > usually the components basically determine themselves > > > (with support from myfaces of course) which includes they need. > > > And the includes are rendered dynamically away without causing > > > double includes. > > > > > > Thus you get the same flexibiliy of the dynamic includes DOJO has > > > solved > > > on javascript level without the speed tradeoffs of the development > > > include of dojo, or the size tradeoffs of the static build of the > parts > > > you need. > > > Are there any supportive infrastructures for such a case? > > > > > > Werner > > > > > > > > > > > > Martin Cooper wrote: > > > > > > > > > > > > On 1/3/06, *Werner Punz* < [EMAIL PROTECTED] <mailto:[EMAIL > > > PROTECTED]> > > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED] >>> wrote: > > > > > > > > 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 > > > > javascripts 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. > > > > > > > > :-( > > > > > > > > > > > > > > > > > > > > > > > >