Opened 8 years ago
Closed 6 years ago
#16562 closed enhancement (wontfix)
support parser's auto-require with _WidgetsInTemplateMixin
Reported by: | gorgoroth | Owned by: | bill |
---|---|---|---|
Priority: | low | Milestone: | 2.0 |
Component: | Dijit | Version: | 1.8.3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
I have created a custom dialog widget based on the dijit/Dialog. This custom widget uses a html template, loaded with dojo/text!, which is assigned to the content member of the widget. The html template contains a declarative widget (dijit/Button). Inside my widget class, at startup(), there are some dom queries to search for some dom nodes. When the dijit/Button dom node is found and I search for the relative button widget with registry.byId( node.id ), it seems the button widget is not instantiated yet so my code fails. Using firebug, I have noticed that when mywidget.startup() is invoked, the parser has not yet finished to download dijit/Button Button.html template, so it seems that the parser has not yet finished his work on my widget template.
Is there a way to wait for the parser when my widget is instantiated with new, before i can safely call startup()?
As a workaround, now I have explicitly requested 'dijit/form/Button' from my widget define() to be sure that button.html is downloaded before my widget will be used. But I hope there is a better solution.
Change History (2)
comment:1 Changed 8 years ago by
Component: | Parser → Dijit |
---|---|
Milestone: | tbd → 2.0 |
Priority: | undecided → low |
Summary: | Parser: wrong parser synchronization using declatative syntax inside dojo dialog content attribute → support parser's auto-require with _WidgetsInTemplateMixin |
Type: | defect → enhancement |
comment:2 Changed 6 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Closing this as wontfix since auto-require itself is inconsistent with how custom elements work, and thus we aren't supporting it in https://github.com/ibm-js/delite.
Auto-require is not supported with templates. This is a known and expected limitation (rather than a bug). Might be able to fix it along with #13782 though.