Forums

Hi all,

According to the YUI3 Widget page, "Parents automatically render their children when rendered".

I'm sure I am missing something simple here, but I'm having some difficulty getting this to work. In the simple example below, what is required for div#test to be recognized as a TestChild instance and have its boundingBox rendered?



Thanks!

Huh. Well, I don't feel as dumb now, lol. The WidgetParent feature list on that YUI3 Widget page is bound to confuse some novices like me given the seemingly built in/out of the box nature of most of the features listed.

Could someone help offer some insight into which of those features a) really come "out of the box" or b) have to implemented in your own code? I will answer what I can; hopefully this topic can become a resource for Googlers like me until there are some guides available.

• It provides a consistent API for creating parent/child relationships. [Out of the box.]
  
• These can be single level relationships (e.g. Tabs in a TabList, or Buttons in a Toolbar) or nested heirarchical relationships (e.g. Menus and MenuItems, or Trees and TreeNodes). [Out of the box, but you must of course establish these relationships.]
  
• Parents are automatically set up as event targets for their children's events, allowing you to leverage custom event bubbling to listen for events higher up in the hierarchy. [Not sure, haven't tried this yet.]
  
• Parents automatically render their children when rendered. [You must implement this yourself.]
  
• Widget Parent augments the ArrayList API, providing a full range of iteration and traversal methods for it's children. [Out of the box.]
  
• It also provides selection support, including support for non-binary selection states (all, none, some). [I honestly have no idea what this means, lol.]
  
• Finally, it provides a sugar layer to simplify adding children to the parent during construction, by supporting an object literal format to initialize children. [Out of the box.]
  

PS: Thank you very much Juan for answering my Widget questions this past week. This has been a bit of a steep learning curve for me and you've been very helpful.

By complete happenstance, I think I may have uncovered some more clues about this - and it 's looking like the rendering of child widgets *is* supposed to happen automatically, out of the box.

Based on your advice and the render lifecycle of TabView, I added the renderUI() method to my example above, then added a generic method called _renderChildren(), following the _renderTabs() method in TabView's renderUI(). I added console.log() statements to each of these methods to make sure they were being called properly before I added code to them, and to my surprise I found my _renderChildren() method being called twice (or once if I removed the renderUI() method entirely). I could only think of one reason for this, and sure enough WidgetParent comes with a built-in _renderChildren() method:

https://github.com/yui/yui3/blob/master ... nt.js#L777

So as long as your WidgetParent is aware of its children *before* the render lifecycle, it looks like those children would indeed be automatically rendered. That makes me think the "correct" solution to this problem is to query for and add the children during the initialization lifecycle. I will give this a try and report back with my results.

Perhaps TabView handles this differently because its child relationships are more complex? I.e., it has two types of children, the tabs and the panels, each with their own properties and behaviors.

Hey Josh,

What is the point of having a child widget outside of the scope of the parent in the DOM structure? Do you have a use-case?

Now, if you just want to auto-render a child using a custom selector instead of relying on the default behavior (rendering children collection under the parent's context box), I remember Satyen introduced a way to handle that a while ago, I can give you more details if needed.

Just keep in mind that the general use case will work like this:



The main reason for this is to allow the parent to control the lifecycle of the children collection.

Best Regards,
Caridy