That's encouraging.  Is there any idea of a timeline (4.1 maybe) for these changes?  Is this a dojo 0.4.3 issue that would require a move to dojo 0.9 (not a simple jar change from what I understand)?  Probably just easier if I ask if you know what the problem is, and/or what a fix would entail.

It'd even be nice if you could point us in the right direction of a fix, we might be able to tackle it on our end and send changes back your way (maybe, might take some convincing to get dev resources for that).

On 9/6/07, richard ratta <Richard.Ratta@sun.com> wrote:

We are working on this issue and trying to improve the file download
situation.

-rick

Steven Bell wrote:

> Hello,
>
> I've been doing evaluations of 3rd party component libraries for a few
> weeks now, and Woodstock is one that my group really likes.
>
> I do have a question on performance though.  Specifically with the
> table, but I'm guessing we'd see this as we got into other components,
> they seem to be sluggish.  A little bit of detective work on my end
> points the finger at getting all the js files.
>
> On a fairly basic table, 20-30 items loaded from an in memory list,
> sorting takes about three seconds from click to final render.  Most if
> this time is spend on just over 40 separate GET calls to get the
> various js files at about 30-45ms each (local network, server is a
> pretty new solaris 10 box, should be more than enough horse power).
>
> Is there any way to preload/cache/inline these js files?  I thought IE
> and Firefox would cache the js after the first load, but it looks like
> the dojo library is actually making the calls.
>
> This is a pretty big deal in terms of company adoption of Woodstock.
> Any ideas would be appreciated.
>
> --
> Thanks,
>
> Steven Bell

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@woodstock.dev.java.net
For additional commands, e-mail: dev-help@woodstock.dev.java.net

--
Regards,

Steven Bell