Forums

Hi!

How do you solve the problem of creating composite widgets with child widgets with interleaving DOM elements?

Assume we have a composite widget (uses widget-parent as extension) and two widgets Foo and Bar both with extensions widget-child. I add them to the composite widgets, but I want to use some structural elements between these two widgets.

I can of course create a child widget of the structural elements and solve the problem, but it feels unjustified to have a widget with no logical function.

with renderUI as follows



The problem here is that this.add() does not alter the DOM until later and therefore my structrual div ends up before the both child widgets.

Another solution is to have a CONTENT_TEMPLATE with all structural elements predefined. However I have not yet found a simple way to insert child widgets into such structure without resorting to CSS selectors to find placeholders in that CONTENT_TEMPLATE. It feels a bit cumbersome.

Am I missing something obvious?

Hi Caridy,

Thanks for your answer. It was almost what I wanted. It pushed me in right direction.

Had some time to play around with the Widget framework and now I understand what is the problem. Basically it is the add() method that does it wrong then it's calling the childs render method.

Lets have this example



As we can se I have two placeholder divs for my two widgets and in between I have span. That span is just for structure, decoration etc

After I create and add my widgets, I still want the structure above, but with the child widgets inserted. So I use the idea you told me.



This does not work. add() just adds evertyhing to the end and not placed around my structure.

However if I do like this, it does work




So when add() calls render() internally it does not keep the position of the element in the DOM tree but moves it. By calling render() prior to to add() the element stays where it should.

Is this behavior intended?

Except for the extra method call to render() I think this is a great solution because then you can define the structure of the widget in your CONTENT_TEMPLATE and the placeholder is passed over as a boundingBox to the child widget which means that you can define parent specific classes for your child and alter between the use of divs and spans depending on the use case for the parent. And when reading the code you get a good overview how this widget is structured. Compare to multiple Y.Node.create() inside renderUI() - much harder to grasp what the end result is.

Of course the you have then rule that a child widget should never have its own boundingBox specific stuff.

One warning thou. I experienced a lot of problem with this solution because I closed my CONTENT_TEMPLATE tags in short form instead of a separate closing tag. It took a while to figure out what went wrong.

By writing like this, you get a different result.



Sincerely Tor

Hi,

If the problem we're trying to solve is "Render my children to a location other than the default [ which is the parent contentBox ]", how about over-riding the method(s) which handle this aspect of parent-child:



And



Note: It sounds like the assumption that parentNode is always used to render the child to is the thing breaking "add()" for you. add() ends up calling _uiAddChild, which probably moves the bounding box from where it's at to the parentNode (which again, is widget-parent's contentBox by default).

Looking at it in isolation, we should probably add a check around it to make sure the child is not already a descendent of the widget-parent boundingBox before defaulting to parentNode. However, looking at it from a higher level, it seems like in general there's a feature here where the widget-parent could support a rendering template which identifies where certain "types" of children are rendered to.

Just thinking through this template feature a little more: For your use case, if I were to add another Foo child (currrently parent-child is designed for a 0..n child setup), what would happen? Should it go into the "foo" div? Or is your parent designed to have exactly 1 Foo and 1 Bar?

Regards,
Satyen

Hi Satyen!




Yes, that is what I have figured out.

I'm wondering about this comment In _uiAddChild() that says



After that it tries to insert the the added childs boundingbox compared to its siblings. Is that valid in this use case?



Yes, I tried to set the _childrenContainer property prior to using add(), becuse that is what is sent as an argument to ._uiAddChild() (used as parentNode), but that did not help either.



Yes, exactly that is what I'm looking for. Using a template for this would be great. That is basically what I'm trying to achieve with my CONTENT_TEMPLATE and using placeholders for each widget. Thats much easier to maintain and adds the possibility to move around widgets inside that template, instead of changing the order of each add()-call.

You get a good overview on the end result, easy to read and understand. The renderUI() tends to grow and can get messy and I rather separate logic from design. By doing like this I can achieve that, but still use javascript.



At the moment, only designed to have exactly 1 Foo and 1 Bar. If more Foos and Bars is needed, we have to add more placeholders to the CONTENT_TEMPLATE -> foo-1, bar-1, foo-2, bar-2 etc.




Thank you, Satyen for spending time on this.

Regards, Tor

Hey Satyen,

Following with the initial example from Tor, I don't see why this doesn't work:



And why do I need to call render() manually like this:



I have a couple of questions:

1- Does a child has to be a sub-dom structure of its parent?
2- Why the parent tries to override the boundingBox even when the child specifically defines the selector?

Here is one of my use-cases:

- I want to create a widget that supports multiple templates. Every template defines placeholders for some child widgets using specific selectors.

I think this is a valid request.

Best Regards,
Caridy