1 p.m.
Ken Paulsen wrote:
> As we've seen, the choice of #2 has impact on the page
author.
>
> Regarding #1... It seems like we agree that it would be desirable to
> have a single tag that can perform three operations:
>
> 1. Insert a facet into the composite implementation as a facet of an
> arbitrary component using the same facet name.
> 2. Insert a facet into the composite implementation as a facet of an
> arbitrary component using a different facet name.
> 3. Insert a facet into the composite implementation as a direct child
> of an arbitrary component.
>
> Our current solution supports #1 via <composite:insertFacet>. We
> support #3 at least to some degree via <composite:renderFacet>,
> though there are subtle differences in behavior between this an
> <composite:renderFacet>.
I agree, we currently support #1 with insertFacet. However, I
disagree that we support #3 at all.
Woops, sorry - the intention of my list wasn't clear. Instead of
"insert", I probably should have said "attach by some means (either
reparent or reference)". If we want to really break it out so we can
see all of the possible operations that we have been considering, we've
got six items:
The reparent cases:
1. Insert a facet into the composite implementation as a facet of an
arbitrary component using the same facet name.
2. Insert a facet into the composite implementation as a facet of an
arbitrary component using a different facet name.
3. Insert a facet into the composite implementation as a direct child of
an arbitrary component.
The reference cases:
4. Reference a facet from the composite implementation as a facet of an
arbitrary component using the same facet name.
5. Reference a facet from the composite implementation as a facet of an
arbitrary component using a different facet name.
6. Reference a facet from the composite implementation as a direct child
of an arbitrary component.
Okay, perhaps there is yet another distinction between our current
reference for rendering purposes only vs reference for everything, but
let's leave that aside because I really don't want to have 9 items! :-)
composite:insertFacet covers case #1 but not #2 and #3. I have been
arguing that it should cover case #2 and #3 (and implicitly #1 since the
solution for #2 solves #1 as well.)
composite:renderFacet definitely covers #6. I have run into one case
where #5 didn't seem to be working (involving nested composite
components). I am not sure whether this is an implementation issue or
by design.
I am still not clear on whether we need to support both approaches
(re-parenting and referencing). We can keep that question simmering.
But for whatever approaches we do support, I think that we need to
support the range of operations - ie. we should support both attaching
the facet as a facet as well as attaching the facet as a (non-facet)
child, whether we are doing re-parenting or referencing or both.
I find the fact that composite:insertFacet supports attaching as a
facet, yet composite:renderFacet supports attaching as a non-facet
inconsistent and confusing.
Does that make sense?
>
> This is getting somewhat repetitive I know (sorry), but I'll ask one
> more time... Can anyone shed some light on why the multi-tag
> approach is preferable to the single tag approach - ie. is there a
> reason why we preferred not to follow the ui:insert model of having a
> single tag address all three of the above operations? It is possible
> that there is a good reason, and if so, I would feel more comfortable
> with our current solution if I knew what that reason was. :-)
As I mentioned above, 1 is a rendering tag which does not effect the
component tree. The other effects the component tree.
Yep, I know this. :-)
So it sounds like you feel that a conscious decision was made that we
needed to support both re-parenting and referencing to some degree. I
am still curious about why we decided that both approaches were
necessary, and why we decided to support slightly different use cases
for each (ie. why we can use composite:renderFacet to render a facet as
a (non-facet) child, but not allow composite:insertFacet to insert as a
(non-facet) child).
If that behavior stays the same, I am in favor of 2 tags. If we
can
change that behavior so we essentially have "symbolic links" from the
facet map and the child list, then we have the same behavior and I'm
in favor of 1 tag.
I get it now and I think we agree on this: If we need to support both
re-parenting and referencing, then, yep, we need two tags. However, if
we do need two tags, then I feel strongly that these two tags should be
consistent in the use cases they support (ie. both should allow
attaching as a facet and as a non-facet, using similar markup).
Funny thing is... we haven't even mentioned composite:insertChildren
(and the fact that we don't have a composite:renderChildren) yet. :-)
Andy