Custom Query (18300 matches)

If you try the example below, and do a mouse over the data point, it's working fine in FF and Chrome, but not in IE8. (Error: Invalid argument).

​http://jsfiddle.net/VjUad/

I have many fields in my real form that are driven (dynamically displayed) by a user selection in a drop-down field. This scenario repeats itself at different levels in the hierarchy. Based on which branches you follow, field are dynamically required as well. The onchange events handle the diplaying of dependent fields and determining which fields to require. I will attach a file that demonstrates the problem in a simplified manner. The attached works fine in 1.3.3, but fails in a number of ways in 1.4.3.

When I setup a FilteringSelect that is required and has an empty default value, a declarative DOM onchange and dijit onChange event handlers, the following problems are encountered in 1.4.3.

1) Runtime error: 'node is undefined'. Removing the attribute value='null' and replacing with defaultValue= resolves the runtime error.

2) If first item is selected in drop-down, neither event handler is triggered.

3) If a user clicks the drop down, doesn't make a selection, and then clicks elsewhere on the form, clicks submit, dijitform.validate() passes even though the user never made a selection to a required field.

The problem (in dojo 1.3 to 1.6, source references for 1.5): If we want to assign id on templated widget's this.domNode via templateString: <div id="MyWidget_${id}" dojoAttachPoint="x">hello world</div>the widget's id and its domNode's id are not affected. Neither is the key in dijit.registry._hash. I have tested this solely on programmatically created widgets var x=new MyWidget({},dojo.byId('foo'));. Note: If we change constructor call to var x=new MyWidget({id:'foo'},dojo.byId('foo')); the effects are obviously the same.

Lifecycle of templated widget and id: The id is being assigned to this in _Widget line 412 (if id present in this.sourceNodeRef) or on line 422 (generated if no sourceNodeRef or no sourceNodeRef.id). The widget gets immediately registered on line 426 dijit.registry.add(this);. So no matter what id modifications are made in templated, widget is already registered at initial id value in dijit.registry._hash Now this.buildRendering(); is called (_Widget, line 427) - which means call to _Templated.buildRendering(). Despite templateString being processed properly in _Templated and proper id being assigned to this.domNode by dijit_Templated._stringRepl (e.g. MyWidget_foo), the id is immediately replaced in _Widget on line 431 via this._applyAttributes(); - and is set back to "foo". The widgetid is obviously also set to "foo".

I see no problem in such an behavior, but this feature (inability to change widget's id via templateString) is nowhere documented. On the countrary - ​http://docs.dojocampus.org/quickstart/writingWidgets/example implies (see template there!) that such an operation is possible - OR that widget's domNode is not being assigned any id. The outcome: if we are building degradable form with ids initially assigned to inputs (as it is the case in zend_Form) - we end up with DUPLICATE ids!

Possible solutions: moving dijit.registry.add(this); behind this.buildRendering call in_Widget (to register widget under proper key==widgetid in dijit.registry._hash)and updating this.id with this.domNode (if this.domNode!=undefined) in _Templated AFTER dijit_Templated._stringRepl was called in dijit_Templated.buildRendering. Additional ID-uniqueness might be necessary. The solution is working, though I am unaware of any side-effects it might bring about.

Example: ​http://jsfiddle.net/XJ9bq/ OR ​http://pastebin.com/FnLFemKc