NumberTextBox (or perhaps some RegEx-stuff) is extremly slow in the new Dojo version 1.2:

I simple test tells the facts, this is the performance-timings in IE7:
Dojo version 1.2.0 (15385)
Time 1: Reset form with NumberTextBox-fields: 500 millis
Time 2: Reset form with ValidationTextBox-fields: 109 millis
Time 3: Inserting value into NumberTextBox-fields: 938 millis
Time 4: Inserting value into ValidationTextBox-fields: 93 millis

Dojo version 1.1.1 (13707)
Time 1: Reset form with NumberTextBox-fields: 79 millis
Time 2: Reset form with ValidationTextBox-fields: 31 millis

Hello,
I've searched for a while and couldn't find something that discuss this issue. If so I'm sorry for this unnecessary thread.

When adding a filteringselect widget programmatically with an existing datastore, it starts a query to the store and creates a ajax request to the server even though there is no value set. Is there a possibilty to change the onload behaviour of this widget?

The problem is that I have a form with lots of filteringselects connected to the same datastore, and the pageloading time is correspondingly very long, when it always starts a request.

Trying to integrate DOJO w/ a pre-existing code base. Any advice on how to troubleshoot the issue below and improve performance?

Background:
A traditional drop down Select box was previously generated by looping through a cursor of data and spitting out the HTML output. The data set has about 3,000 items in it, and is fast when the user navigates up and down the traditional list.

Issue:

Hi,

Is there any way to tune the performance of parsing widgets on page load. sometimes according to the size of the page, the loading time is really remarkable and we see a flicker in the components of page.

Could we disable parsing all the tags of page and using a solution such as parseWidgets=false described at http://dojo.jot.com/PerformanceTuning.

In fact, I noticed that the mentioned solution deos not work in version 1.1.

Thanks.

I have a dilemma. I am tasked to make a final decision for my company, between Dojo, and EXTjs, as our framework for all our clients. Our developers are split right down the middle, between those who like Dojo's orthodoxy and stability, vs those who see it being brushed aside by EXTjs, with its many widgets that save so much time, and provide so much UI sizzle. It just overpowers most arguments the Dojo proponents are making. They also point to what they see as a noticable slowdown in Dojo projects, community, and general enthusiasm.

Trying to integrate DOJO w/ a pre-existing code base. Any advice on how to troubleshoot the issue below and improve performance?

Background:
A traditional drop down Select box was previously generated by looping through a cursor of data and spitting out the HTML output. The data set has about 3,000 items in it, and is fast when the user navigates up and down the traditional list.

Issue:

Hello, checking out with Firebug I noticed that several files are loaded directly from aolcdn.com instead my local copy of dojo and this happens even if those file are present in my local copy.
Is it possible to use the local copy instead teh remote one?
I'm asking that because I would like to reduce the loading time and since the application I'm working on will be deployed within a LAN with local copy I can have better performance.

Thanks and have a nice day!

hi everybody!

When I add a large number of dijit TextBox widgets to my page (say around 75). the focusing of the TextBox widgets via mouse click becomes really slow in IE6 and IE7 (around 500ms). Tabbing the focus works a little faster but the lag is still noticable. In addition, these TextBox widgets are causing the menu on my page to lag.

On Firefox 2, everything works just fine.

I'm using a nightly build from about a week ago.

anyone out there seeing something similar? any suggestions?

thanks

1. A quick tutorial on writing dojo.query() extensions. It's fast, easy, and because we show you how to package it up as a Dojo module, it won't drag down your site performance
2. The awesomeness that is WebKit just won't quit and we've already added support for the native code path to what will become Dojo 1.1 (look for it in tonight's build). Of course, because the design of Dojo is layered, your dojo.query() extensions work no matter what selector engine Dojo picks as being fastest for a particular search.