Chaining startup()?

[seb-pereira]

It would be nice for startup() to return 'this' in order to have a single chain like this when creating a new instance:

var widget = new FormValueWidgetTest()
.placeAt(parentNode)
.startup();

[wkeese]

It looks like you want to chain placeAt(), not startup()?

Actually, it seems fine to chain both of them but I think I also want to change placeAt() to call startup automatically. Just need to think about it a bit more.

[seb-pereira]

In this specific case this is startup() that needs to return 'this', otherwise the assignment to the widget variable fails.

[wkeese]

Ah OK, I see. And placeAt() already returns this.

[seb-pereira]

Exact, placeAt() already returns this so we can write
var widget = new FormValueWidgetTest().placeAt(parentNode);

[wkeese]

OK... well it sounds like a nice idea. The problem is that even if I make Widget#startup() return this, there are many other startup() methods in subclasses that don't return this.

Note that startup() is chained so there's no dcl.superCall() or dcl.after() needed when a subclass adds tasks to do at startup.

What do you think?

[seb-pereira]

I see. The only solution I can think of would be to define a method in Widget that call startup and return this:

// in Widget
start: function () {
    this.startup();
    return this;
},

// The application should call start() instead of startup:
var widget = new FormValueWidgetTest()
.placeAt(parentNode)
.start();

Of course the start() method would not be meant to be overridden by subclasses.

[wkeese]

See also #287. We might get rid of startup() altogether.

[wkeese]

I'm closing this since startup() is deprecated and will be removed in 0.7 altogether.