Sean Comerford wrote:
> Steve,
>
> For what it's worth, I believe most of what you're seeing stems from Dojo's
> 0.4.x package system - it's a nifty idea but does tend to generate a ton of
> requests. You'll see behavior like that whenever you seriously use Dojo (not
> just with Woodstock).
>
Correct. I believe this is what Dan concluded when he did the analysis
a week or 2 ago, and I believe he proposed a series of steps he plans to
implement to address this. I can't recall if it also included an
upgrade to dojo 0.9. I'm sure Dan can provide more details when get
backs from vacation mid next week.
> I'll let the Lockhart experts comment on potential Lockhart specific remedies
>
Lockhart? What's Lockhart? Sean, do you have "inside" information the
rest of the community doesn't? ;-)
> but with Dojo in general, the best way to use it on a true production class,
> high traffic site is x-domain via a CDN - see:
>
> http://dojotoolkit.org/node/17
>
> Admittedly I've never looked into having the Woodstock components pull Dojo
> from a CDN like AOL but I suspect making that work would be difficult if not
> actually impossible. You need to be using a cross domain Dojo build in the
> first place and I'm not sure Woodstock does / if you'd hit build compatability
> issues right away if you tried this.
>
> --- Steven Bell <bell.steven_at_gmail.com> wrote:
>
>
>> 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_at_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_at_woodstock.dev.java.net
>>> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>>>
>>>
>>>
>> --
>> Regards,
>>
>> Steven Bell
>>
>>
>
>
> later,
> Sean
> http://seanc.us
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>
>