AnsweredAssumed Answered

AMD confusion about parser.parse

Question asked by evtguy on May 22, 2015
Latest reply on May 26, 2015 by evtguy

I'm jumping off the deep end and starting to convert some apps to AMD style that were originally written in legacy dojo. One thing I've picked up about migrating to AMD is that the legacy practice of doing this:

 

<script type ="text/javascript">
var dojoConfig = {parseOnLoad: true};
</script>

 

in the HTML header section has been replaced by doing this:

 

ready(function() {
     parser.parse();
     .....
}

 

down in the Javascript code. I never questioned this; I just did it. In my current work trying to migrate a legacy app to AMD, I ran into a maddening issue where my attempts to establish a listener event on a dojo form that had two radio checkboxes as choices:

 

// Event listener to enable/disable controls based on the input method chosen
dijit.byId("frmEndMethod").on('change', function() {
....
});

 

would always error out because dijit.byId() couldn't find the widget and thus, returned undefined. The code was within the ready(function() {...}); so it should have no problems finding it. In fact, I could type "dijit.byId("frmEndMethod")" into the console after page load and it does return the dijit. No matter what I tried, I could not get this to work. Then I reverted back the the legacy variable declaration in the header and commented out parser.parse() in my JS code.

 

Surprise, surprise- it loaded without error and the event now triggers. So what gives? Am I "wrong" to still use the dojoConfig variable with AMD style coding? I mean, it seems to work, which is the whole point but is there something I'm missing?

 

Steve

Outcomes