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
