1/ ability to use data-dojo-attach-* in the default View templates. This will close #22 (with example).
2/ ability to switch the default View class by another one. For that:
a/ all Views are now created by the Load controller and not some by Load and some by main (the "root" view)
b/ for being able to create all Views after controllers creation, the controllers now by default listen to events on the Application not on the DOM node application. They can still listen to events on domNode of the app but must listen first to "domNode" event on the app to be notified of root domNode changes. This event is fired after the "root" view has been created on the new "init" event by the Load controller.
c/ A parameter has been added to the view definition called "type". It allows to specify the MID of View class. Alternatively one can also switch to another Load controller to create its own views (see example).
Ideally I think we should entirely get rid of that "root" view which allow to get rid of the subtleties in b/.
This also contains an example of how to use the new ability to switch View class to implement #128 (use of DTL in View templates). This should also close #132.
Another pull request will follow later to enhance the build system extension to support new type parameter on view definition.
There are several parts to this request:
1/ ability to use data-dojo-attach-* in the default View templates. This will close #22 (with example).
2/ ability to switch the default View class by another one. For that: a/ all Views are now created by the Load controller and not some by Load and some by main (the "root" view) b/ for being able to create all Views after controllers creation, the controllers now by default listen to events on the Application not on the DOM node application. They can still listen to events on domNode of the app but must listen first to "domNode" event on the app to be notified of root domNode changes. This event is fired after the "root" view has been created on the new "init" event by the Load controller. c/ A parameter has been added to the view definition called "type". It allows to specify the MID of View class. Alternatively one can also switch to another Load controller to create its own views (see example).
Ideally I think we should entirely get rid of that "root" view which allow to get rid of the subtleties in b/.
This also contains an example of how to use the new ability to switch View class to implement #128 (use of DTL in View templates). This should also close #132.
Another pull request will follow later to enhance the build system extension to support new type parameter on view definition.