The situation you are facing is, that very very many nodes are created in the DOM, and programatically. IE has poor performance for this, being held back by the javascript engine. Yikes huh?!
Your goal is to define as much as possible beforehand as opposed to override this during runtime. By this i mean setting parameters in the data-dojo-props / construct arguments. This especially applies for stuff like onClick handlers etc. You'd achieve this by doing like such:
var MyConstruct = dojo.define("foo.MyConstruct", [ /* inheritance */ dijit.form.ValidationTextBox ], function() {
// instead of setting properties during construct, preset those which are possible
constraints: { min: 0, max: 100 },
postMixInArguments: function() {
this.inherited(arguments); // call widget first
if(this.constructParameter) ; // act on it
},
// implement any overrides you otherwise would need
// and for minimal runtime overhead, redefine the private version, like _onBlur
// copy the source and change what you need
onBlur: function () {
// an event override example
}
});
But; why did NumberSpinners > NumberTextBoxes reduce by 50%? This is why:
Template TextBox
<div class="dijit dijitReset dijitInline dijitLeft" id="widget_${id}" role="presentation"
><div class="dijitReset dijitInputField dijitInputContainer"
><input class="dijitReset dijitInputInner" data-dojo-attach-point='textbox,focusNode' autocomplete="off"
${!nameAttrSetting} type='${type}'
/></div
></div>
Template Spinner
<div class="dijit dijitReset dijitInline dijitLeft"
id="widget_${id}" role="presentation"
><div class="dijitReset dijitButtonNode dijitSpinnerButtonContainer"
><input class="dijitReset dijitInputField dijitSpinnerButtonInner" type="text" tabIndex="-1" readonly="readonly" role="presentation"
/><div class="dijitReset dijitLeft dijitButtonNode dijitArrowButton dijitUpArrowButton"
data-dojo-attach-point="upArrowNode"
><div class="dijitArrowButtonInner"
><input class="dijitReset dijitInputField" value="▲" type="text" tabIndex="-1" readonly="readonly" role="presentation"
${_buttonInputDisabled}
/></div
></div
><div class="dijitReset dijitLeft dijitButtonNode dijitArrowButton dijitDownArrowButton"
data-dojo-attach-point="downArrowNode"
><div class="dijitArrowButtonInner"
><input class="dijitReset dijitInputField" value="▼" type="text" tabIndex="-1" readonly="readonly" role="presentation"
${_buttonInputDisabled}
/></div
></div
></div
><div class='dijitReset dijitValidationContainer'
><input class="dijitReset dijitInputField dijitValidationIcon dijitValidationInner" value="Χ" type="text" tabIndex="-1" readonly="readonly" role="presentation"
/></div
><div class="dijitReset dijitInputField dijitInputContainer"
><input class='dijitReset dijitInputInner' data-dojo-attach-point="textbox,focusNode" type="${type}" data-dojo-attach-event="onkeypress:_onKeyPress"
role="spinbutton" autocomplete="off" ${!nameAttrSetting}
/></div
></div>
There is not much one could do with the TextBox template to optimize it, only entrypoint would be the ${type} parameter which is set using regular exp replacement via _getTypeAttr. in postMixInProps (before _TemplatedMixin runs and generates DOM) the value is overridden into 'text' even if anything else is specified. Allthough - not sure how this would implicate - one might want to take away the focusNode + FocusMixin, but i will not go into that.
There's a little quirk handling in the dijit/form/MappedTextBox (which creates a hidden <input>
, containing the 'true' value see http://bugs.dojotoolkit.org/ticket/8660. This has put a regexp replace on 'this.name' to fix problems - leaving out the name attribute on your input field will take care of that (if possible use Id instead).
Template ValidationTextBox
The main reason for using NumberTextBox would be the range limitation right? In order for that particular module to load, a number of mixins are done - but basically they are based on the ValidationTextBox. This offers a .validate
functionality and shows messages if needed. The above note on removing focusmixin will take the messaging out of business since they act on the onBlur events.
If you were to use ValidationTextBox as opposed to NumberTextBox and implement the range checks by custom functionality i believe it would work wonders. A good deal of eval'd code is run ontop of validationtextbox to make it numbertextboxes - some of which probably is overhead in your case.
<div class="dijit dijitReset dijitInline dijitLeft"
id="widget_${id}" role="presentation"
><div class='dijitReset dijitValidationContainer'
><input class="dijitReset dijitInputField dijitValidationIcon dijitValidationInner" value="Χ " type="text" tabIndex="-1" readonly="readonly" role="presentation"
/></div
><div class="dijitReset dijitInputField dijitInputContainer"
><input class="dijitReset dijitInputInner" data-dojo-attach-point='textbox,focusNode' autocomplete="off"
${!nameAttrSetting} type='${type}'
/></div
></div>
a sample override to the validation:
dijit.byId("validationTextBoxNodeId").validator = function(value, constraints){
// Check that email has not been used yet.
if(some-checks){
return true;
}else{
return false;
}
}