dojo.behavior needs to be able to more easily create instances of classes and widgets from rules

[alex]

it would be preferable to allow dojo.behavior() rules to specify the name of a class to instantiate and potentially pass parameters into the constructors for those classes. It should probably also use the markupFactory convention implemented by dojo.parser().

[ptwobrussell]

I also wonder if there's value in adding an optional andApply argument to the add method so that you don't have to add then apply if you know you want to apply right away? IOW, why is that inherently a two step process?

Actually, that was the reason I found this ticket. What exactly are the use cases for not having an andApply? It seems like a lot of times, you'll want to apply something and be done with it. I imagine there are times you would want to add, wait a while, then apply or add, add, add, then apply, but I am having a hard time coming up with them.

Any feedback would be really helpful so that I can better explain the rationale in the book.

dante also suggested perhaps there should be a remove method at some point?

[dante]

regarding this ticket: perhaps 'instantiate' is the best keyword to look for, as it matches the other api's set forth. Also, it might be better to wait on dojo.parser.instantiate() to work as described in #7090 (actually there was a more intriguing conversation as the result of #7090 which made more sense than the description) ... then it would almost be a no-op, though adds a parser dependency to behavior. something to consider. marking this 'future' for now, as its entirely valid but not in this timeframe.

@ptwobrussell: I agree w/ andApply to a point, and opted for .apply() accepting an object to call .add with and then immediately .apply but it adds confusion to my overall dream of handles being returned so you could destroy/remove a set of behaviors by handle. see: #7418