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.
> > > >
> > > > :-(
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
