I brought this up in conversation with Satyen previously, but didn't ticket it. A suggestion I had to simplify WidgetStdMod is to add methods head(), body(), and foot() to the host class. These methods would return the Node corresponding to the yui3-widget-hd, -bd, and -ft respectively. If the Nodes have not yet been created, they would be at that point. This would allow
var overlay = new Y.Overlay();
overlay.head().setContent("Title text");
overlay.body().empty();
etc

It is significantly more terse than overlay.getStdModNode(Y.WidgetStdMod.HEAD) and more intuitive than overlay.setStdModContent(Y.WidgetStdMod.BODY, "New content");

The returned nodes need only be generated on request. They could be attached to the container element in either renderUI or syncUI.

I agree it does get a bit verbose using the full method/constants, and those shortcuts would be welcome. Where I've run into issues often is in creating extensions that also mix in WidgetParent, I want to set the _defaultChildContainer to one of the StdMod nodes, but as it stands I have to catch the rendering of children and halt it until the syncUI phase when those nodes exist.

Luke, really like that idea, not totally sold on the naming:
header, head, hd | body, bd | footer, foot, ft

Greg, I ran into the same issue and also solved it by doing work in syncUI, hopefully this will be fixed in the next release...

I checked in some changes to WidgetStdMod that fixes this issue. The problem was being caused by the fact that at renderUI(), the attribute change listeners were not set up. I moved the setup of those listeners to the _renderUIStdMod() method. The rest of the listeners are still being setup in _bindUIStdMod().

I also added the convenience methods head(), body(), foot() that return a Y.Node instance of the appropriate sections.

I added the test case provided by Eduardo to the src/widget-stdmod/tests/ directory. Give it a try and let me know what you think. I'll change the status to checkedin for now.

I'm not a big fan of head(), foot(), body() - I'd prefer getHeader(), getFooter(), getBody() to make what they do more obvious. In general I'm of the opinion that methods should be verbs, not nouns. They're doing something, not naming something.

I took out head(), body(), foot() but didn't put in getHeader(), getFooter(), getBody() just because I think it may confuse newcomers to the library with something like get('header') - probably just a naming issue.

That's something that I can add in for the next PR. I'm closing this ticket because the issue mentioned here is fixed to the best of my knowledge. I'll reopen a new ticket for the std-mod convenience method and link it here.