6:29 p.m.
Gang -
As currently specified, composite:insertFacet's "name" attribute serves
two purposes:
1. It identifies the name of the facet on the containing composite
component to insert.
2. It identifies the name of the facet on the target component into
which the facet is being inserted.
As a result, the name of the facet exposed by the composite component
must match the name of the facet on the implementation component into
which the facet is being inserted. So, for example, if I have a
composite component as follows:
<composite:interface>
<composite:facet name="caption"/>
</composite:interface>
<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
</composite:implementation>
Everything is happy, since both the composite component and the
h:panelGrid expose a "caption" facet.
However, if I want to define a composite components with two h:panelGrid
components and two captions:
<composite:interface>
<composite:facet name="caption"/>
<composite:facet name="backupCaption"/>
</composite:interface>
<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
<h:panelGrid>
<!-- Uh oh. -->
<composite:insertFacet name="backupCaption"/>
</h:panelGrid>
</composite:implementation>
I am out of luck, since I now have a mismatch between the composite
component facet name and the h:panelGrid facet name. Or, at least, I
think I am out of luck... Am I missing some way to handle this use case?
If the spec does not yet provide a solution for this, I think that we
could/should solve this in one of two ways:
1. Add an attribute to composite:insertFacet that allows a target facet
name to be specified:
<h:panelGrid>
<composite:insertFacet name="backupCaption"
targetName="caption"/>
</h:panelGrid>
2. Specify that the target facet name can be picked up from a wrapping
<f:facet> tag:
<h:panelGrid>
<f:facet name="caption">
<composite:insertFacet name="backupCaption"/>
</f:facet>
</h:panelGrid>
I prefer #2 since is consistent with typical facet usage.
Thoughts?
BTW, this seems like a fairly severe limitation to me. Is there any
chance that we can correct this by spec'ing the behavior from #2 in the
next MR? Of course, I am not sure what the rules are for MRs... In
this case we aren't so much adding new APIs (no new attributes/tags) so
much as specifying behavior for a particular use of existing APIs
(<composite:insertFacet> inside of <f:facet>) that was previously
unspecified.
Andy
7:22 p.m.
I remember discussing this issue on one of our phone calls (when it was
still considered an "attached object"). It was one of my issues I was
concerned with (for all "attached objects") and thought we had arrived
at a consensus that we could *default* to the same name, but have a way
to explicitly provide a name to solve the problem Andy has correctly
pointed out. I might have to go back and listen to our old audio
recordings....
IMHO, this should be solved quickly.
Ken
Andy Schwartz wrote:
Gang -
As currently specified, composite:insertFacet's "name" attribute
serves two purposes:
1. It identifies the name of the facet on the containing composite
component to insert.
2. It identifies the name of the facet on the target component into
which the facet is being inserted.
As a result, the name of the facet exposed by the composite component
must match the name of the facet on the implementation component into
which the facet is being inserted. So, for example, if I have a
composite component as follows:
<composite:interface>
<composite:facet name="caption"/>
</composite:interface>
<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
</composite:implementation>
Everything is happy, since both the composite component and the
h:panelGrid expose a "caption" facet.
However, if I want to define a composite components with two
h:panelGrid components and two captions:
<composite:interface>
<composite:facet name="caption"/>
<composite:facet name="backupCaption"/>
</composite:interface>
<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
<h:panelGrid>
<!-- Uh oh. -->
<composite:insertFacet name="backupCaption"/>
</h:panelGrid>
</composite:implementation>
I am out of luck, since I now have a mismatch between the composite
component facet name and the h:panelGrid facet name. Or, at least, I
think I am out of luck... Am I missing some way to handle this use case?
If the spec does not yet provide a solution for this, I think that we
could/should solve this in one of two ways:
1. Add an attribute to composite:insertFacet that allows a target
facet name to be specified:
<h:panelGrid>
<composite:insertFacet name="backupCaption"
targetName="caption"/>
</h:panelGrid>
2. Specify that the target facet name can be picked up from a wrapping
<f:facet> tag:
<h:panelGrid>
<f:facet name="caption">
<composite:insertFacet name="backupCaption"/>
</f:facet>
</h:panelGrid>
I prefer #2 since is consistent with typical facet usage.
Thoughts?
BTW, this seems like a fairly severe limitation to me. Is there any
chance that we can correct this by spec'ing the behavior from #2 in
the next MR? Of course, I am not sure what the rules are for MRs...
In this case we aren't so much adding new APIs (no new
attributes/tags) so much as specifying behavior for a particular use
of existing APIs (<composite:insertFacet> inside of <f:facet>) that
was previously unspecified.
Andy
7:48 p.m.
On 09/15/2009 04:29 PM, Andy Schwartz wrote:
Gang -
As currently specified, composite:insertFacet's "name" attribute
serves two purposes:
1. It identifies the name of the facet on the containing composite
component to insert.
2. It identifies the name of the facet on the target component into
which the facet is being inserted.
As a result, the name of the facet exposed by the composite component
must match the name of the facet on the implementation component into
which the facet is being inserted. So, for example, if I have a
composite component as follows:
<composite:interface>
<composite:facet name="caption"/>
</composite:interface>
<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
</composite:implementation>
Everything is happy, since both the composite component and the
h:panelGrid expose a "caption" facet.
However, if I want to define a composite components with two
h:panelGrid components and two captions:
<composite:interface>
<composite:facet name="caption"/>
<composite:facet name="backupCaption"/>
</composite:interface>
<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
<h:panelGrid>
<!-- Uh oh. -->
<composite:insertFacet name="backupCaption"/>
</h:panelGrid>
</composite:implementation>
I am out of luck, since I now have a mismatch between the composite
component facet name and the h:panelGrid facet name. Or, at least, I
think I am out of luck... Am I missing some way to handle this use case?
If the spec does not yet provide a solution for this, I think that we
could/should solve this in one of two ways:
1. Add an attribute to composite:insertFacet that allows a target
facet name to be specified:
<h:panelGrid>
<composite:insertFacet name="backupCaption"
targetName="caption"/>
</h:panelGrid>
2. Specify that the target facet name can be picked up from a wrapping
<f:facet> tag:
<h:panelGrid>
<f:facet name="caption">
<composite:insertFacet name="backupCaption"/>
</f:facet>
</h:panelGrid>
I prefer #2 since is consistent with typical facet usage.
#2 seems more consistent
for me. Francly, this is behavior that I
expected for "insertFacet" tag.
Thoughts?
BTW, this seems like a fairly severe limitation to me. Is there any
chance that we can correct this by spec'ing the behavior from #2 in
the next MR? Of course, I am not sure what the rules are for MRs...
In this case we aren't so much adding new APIs (no new
attributes/tags) so much as specifying behavior for a particular use
of existing APIs (<composite:insertFacet> inside of <f:facet>) that
was previously unspecified.
Andy
9:17 a.m.
+1 for #2. Exactly the arrangement I would expect.
- Dan Allen
Sent from my Android-powered G1 phone:
An open platform for carriers, developers
and consumers.
On Sep 15, 2009 8:49 PM, "Alaxander Smirnov" <asmirnov(a)exadel.com> wrote:
On 09/15/2009 04:29 PM, Andy Schwartz wrote: > > Gang - > > As currently
specified, composite:inse...
#2 seems more consistent for me. Francly, this is behavior that I expected
for "insertFacet" tag.
> > Thoughts? > > BTW, this seems like a fairly severe
limitation to me.
Is there any chance tha...
12:06 a.m.
Why would you not use <composite:renderFacet name="..." /> in this case?
Why does <composite:insertFacet /> exist except for convenience?
<h:panelGrid>
<f:facet name="caption">
<composite:renderFacet name="caption"/>
</f:facet>
</h:panelGrid>
vs.
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
Since renderFacet already transfers its children into the parent
component, <f:facet> could be used to propagate those children upward...
that seems like a simple enough solution to me unless I am missing a use
case. If I'm right, this is potentially duplicate functionality,
potentially confusing since there are two very similar tags with similar
functionality, and potentially complex to implement (not a super big
consideration, but simplicity should always be the goal.)
My suggestion in this case is to remove <cc:insertFacet /> from the spec
altogether, leave the repositioning to be done manually -- with not much
extra code (how deep are people really going to nest facets most of the
time? It's not that much extra work and provides just as much control.)
--Lincoln
PS. Going a step further, "renderFacet" is really inserting the facet
children, and could be renamed to "insertFacet" should we decide to do
away with the current "insertFacet" - I find that the word "render"
is
slightly misleading, since it's not truly causing a render to occur,
simply inserting children into a different parent.
Tag insertFacet
________________________________________________________________________
The presence of this tag in a <composite:implementation> section must
cause the named facet to be taken from the facet map of the top level
component and inserted as a facet child of the component in which this
element is nested.
Tag renderFacet
________________________________________________________________________
This element is used in the <composite:implementation> section. The
facet with the name equal to the value of the name attribute, given by
the page author in the using page, will be rendered at this point in the
composite component PDL page.
The implementation of this tag handler must insert a component with
component-type javax.faces.Output and renderer-type
javax.faces.CompositeFacet as a child at this point in the component
tree.
The implementation of this tag handler must store an attribute into the
created component's attribute map under the key given by the value of
the symbolic constant UIComponent.FACETS_KEY. The value for this key
must be the evaluated value of the "name" attribute.
On Tue, 2009-09-15 at 19:29 -0400, Andy Schwartz wrote:
>
> <composite:interface>
> <composite:facet name="caption"/>
> <composite:facet name="backupCaption"/>
> </composite:interface>
>
> <composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
>
> <h:panelGrid>
> <!-- Uh oh. -->
> <composite:insertFacet name="backupCaption"/>
> </h:panelGrid>
> </composite:implementation>
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF
5364
days inactive
5366
days old
jsr-314-open-mirror@lists.jboss.org
4 comments
5 participants
participants (5)
-
Alaxander Smirnov -
Andy Schwartz -
Dan Allen -
Ken Paulsen -
Lincoln Baxter, III