On 1/3/06, Werner Punz <[EMAIL PROTECTED]> wrote:
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. ;-)
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
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
> > _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.
> >
> > :-(
> >
> >
> >
>
>
