Hi Alex, 2018-06-30 8:06 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
> > > On 6/29/18, 11:29 AM, "carlos.rov...@gmail.com on behalf of Carlos > Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> > wrote: > > Hi Alex, > > thanks for the explanation I think finaly understand the main > difference > between Group and Container. Although, I see Group seems to have many > things already setup to be able to do have this feature. Don't know if > having two separate components make sense, or there's more differences? > > IIRC, Group has some code to implement an interface that allows layouts to > find the right children, and could therefore have an internal actual parent > for its children, but Group never does for PAYG reasons, since lots of > times you don't need an internal parent. The code in Group is effectively > a degenerate case, but done that way so the Layouts can find the children > in the same way as in a Container. > > Container always creates an internal actual parent for the children. For > PAYG reasons, we offer these two ready-to-go components. If you looked at > the first FlexJS examples, there was no Group and thus there were twice as > many Divs in the DOM, one for the Container and one for the internal actual > parent. That was not PAYG. > > If we wanted to rename things, I would recommend dropping "Group" and > calling that Container (and not have an internal actual parent) and the > current Container would be more explicitly named, like > ContainerWithContentArea or something like that. > For me actual names "Group" and "Container" are ok now that I understand the differences, I think the names are capturing the essence. I'm not a fan of names like "XWithYAndZ". For me is a matter of update the comment description in both classes to describe the differences between both. > > COMPILE::JS > { > nav.appendChild(c.positioner); > (c as IUIBase).addedToParent(); > } > } > > So I have a "nav" html nested tag, and there's where things are added. > Is still early code, so maybe I should refactor it, but is a very > concrete > use for HTML (maybe SWF will not need this) > > I think you can create a component like ContainerContentArea and have it > create some other html element besides Div and set that as the IContentView > in a Container. There may be some support missing on the JS side. You > might want to see how Panel does it. > > I must say that as I dig more and more in new html5 components and > layouts > I see each time that things use to be created nesting some tags to > have the > final desired use case. In SWF things can be more simpler or less > nesting > (but as normal, more code too) > > Some of our component sets (or maybe just some of the components) are just > intended to encapsulate common DOM patterns. So if HTML5 nests tags, that > shouldn't be a problem, it is just the pattern you are trying to > encapsulate. The View should take care of that encapsulation. > I have things working right now, but I think as all code is a "first draft", I think we could revisit it to upgrade to a better, reusable and extendable class as Jewel settles more and more. > > I think there should be a distinction in the framework between a > "container" which can contain an arbitrary set of children, and a "control" > which might be composed of children, but you aren't supposed to know about > that, sort of like Web Components. So if you are creating Controls and > know the children in the "sub-DOM" then I would recommend creating that > sub-DOM in the View. If you are creating new containers, then it makes > more sense to base your Container on GroupBase or ContainerBase. > Right, I'm agree with that. I'll try to get back over the actual code of this case to try somethings in that way. It's more easy always to rework from a working version to get a better one thanks! :) > > HTH, > -Alex > > 2018-06-29 18:13 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > > > Container creates a ContainerContentArea as its child and then all > > children become children of the ContainerContentArea. Group does > not do > > that. The concept of having an inner content area forms the basis of > > complex containers with "chrome" around it, such as Panel. I'm not > sure > > how your requirements about positioner are different from what > Container > > and Panel do, so you might need to provide more detail about the > > differences. > > > > HTH, > > -Alex > > > > On 6/29/18, 8:17 AM, "carlos.rov...@gmail.com on behalf of Carlos > > Rovira" <carlos.rov...@gmail.com on behalf of > carlosrov...@apache.org> > > wrote: > > > > Hi, > > > > I trying to find the best route to have a container component > that has > > some > > nested html tag structure and adding child elements will be > added to > > the > > inner element, but the rest of normal behavior (id, listeners, > etc..) > > will > > be referencing the positioner. > > > > What's the best way to do this? Use Group or Container? what I > should > > override? get host() method in BeadViewBase should be override? > how? > > > > Hope you could point to the best way of doing this > > > > thanks > > > > -- > > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url= > > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui% > 40adobe.com% > > 7Cbef963261fdf463682d308d5ddd37182%7Cfa7b1b5a7b34438794aed2c178de > > cee1%7C0%7C1%7C636658822573164461&sdata= > kLJNuz8V8r46O6YvTUm5TuQHx78VXn > > rPSbAbp2p%2BOLg%3D&reserved=0 > > > > > > > > > -- > Carlos Rovira > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7Caeeff59c04124c78a2cb08d5ddee4845%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636658937842133607&sdata=eQkL2bkhxySrevK%2FS0Vg2cIV% > 2F8IcaBi2C%2FE3gkFqxws%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira