<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
+1<BR>
<BR>
As long as we can have multiple <ui:insert> like tags... the only problem with <ui:insert> in Facelets was that there was no way to divide inserted tags and deliver them to different parents within the Component.<BR>
<BR>
--Lincoln<BR>
<BR>
On Thu, 2009-09-24 at 18:55 -0400, Andy Schwartz wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Gang -
I have been spending a lot of time thinking about this topic and reading
the doc/looking at the source code. I can now say that I definitely
understand the difference between composite:insertFacet and
composite:renderFacet. :-) However, I am still confused about why we
decided to go with two separate tags and wanted to share my thoughts.
FWIW, I realize that it is like a year late to be bringing this up, but
thought it was important to discuss even if our options are limited at
this point.
Let's start by taking a look at composite:insertFacet:
<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
</composite:implementation>
In the above case, the component specified for the "caption" facet ends
up in the facet map of the h:panelGrid component. This has certain
implications - eg. the component's parent property will point to the
h:panelGrid instead of the composite component. If we happen to insert
the facet into a NamingContainer, the client id will reflect this.
Currently we provide no way to insert a composite component's facet into
one of the composite's implementation components as a plain old
(non-facet) child. So, if instead of inserting the "caption" facet as a
facet on an h:panelGrid, I wanted to insert it as a (non-facet) child of
an h:panelGroup, eg:
<composite:implementation>
<h:panelGroup>
<!-- Insert the facet as a direct child here -->
</h:panelGroup>
</composite:implementation>
I cannot do that. Or, at least, I cannot do that with the same
semantics as <composite:insertFacet>, where the component specified via
the facet ends up as a child of the containing component (the h:panelGroup).
I can, however, use composite:renderFacet:
<composite:implementation>
<h:panelGroup>
<composite:renderFacet name="caption"/>
</h:panelGroup>
</composite:implementation>
This will cause the facet to be rendered as a child of the h:panelGroup,
but without being a child of the h:panelGroup.
This raises a number of questions. Why do we re-parent the facet
component when we want the component to be used by the parent component
as a facet, but not when we want the component to be used by the parent
as a direct child? Is there a reason why we need to treat the direct
child case differently (not re-parent) than the facet case (re-parent)?
Is there some benefit to having subtly different behavior between these
two cases?
My feeling is that the good old Facelets ui:insert tag got this right.
Facelets uses a single tag to handle insertion of ui:define'd components
into the template, regardless of whether the components are being
inserted as facets or directly children. So, for example, assuming I've
got a template that allows insertion of a "foo" component, I can do
either this:
<h:panelGrid>
<f:facet name="caption">
<!-- Insert the "foo" component into the "caption" facet -->
<ui:insert name="foo"/>
</f:facet>
</h:panelGrid>
Or this:
<h:panelGroup>
<!-- Insert the "foo" component as a non-facet child -->
<ui:insert name="foo"/>
</h:panelGroup>
While the first case inserts the component as a facet and the second as
a direct child, both have the same semantics - ie. in both cases the
component that is being inserted ends up as a child of the parent
component that the child is being inserted into.
Actually, Facelets provides an API that is specifically designed to
handle this type of insertion: TemplateClient. The TemplateClient API
allows for clean/efficient insertion of included content into
templates. I believe that ui:define/ui:insert use this to insert
included content directly into the target location, avoiding the need to
re-locate the included components from one parent to another. This has
benefits when re-applying tags over a restored component tree, since
there is no need to repeatedly re-create (or re-locate) these components.
After thinking this through, one other question that I am left with is:
Is there a reason why we did not follow the ui:insert approach?
Yes, I realize that this is a moot point now, and no reason to dwell on
this, but I am still curious as to whether there were
limitations/problems with the ui:insert mechanism that prevented us from
following this precedent.
If we had the ability to revisit the design now, my preferred solution
would be to:
1. Deprecate/remove composite:renderFacet.
2. Re-spec composite:insertFacet to match the behavior of ui:insert.
I prefer this approach because I feel that we should share a single
insertion behavior across all of these use cases. The fact that we have
3 subtly different mechanisms is, well... bad. I also think that the
ui:insert approach has already been proven, which is in part why I favor
that approach.
Of course, I don't imagine that we have the ability to make this change
given that the JSF 2.0 spec has been final for some time now, and this
would be a significant change.
I suppose my second choice would be to deprecate both
composite:renderFacet/composite:insertFacet in JSF 2.1 and replace both
of these with a new composite:insert tag that matches ui:insert behavior.
Getting back to our original problem of not having control over the
"target" facet name:
> 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 still prefer #1 as this is closer to ui:insert behavior, but given
that I have more fundamental reservations about
composite:insertFacet/composite:renderFacet, I don't feel especially
strongly about forcing #1 if people prefer #2.
Andy
Ken Paulsen wrote:
>
> When / where should this discussion take place? Do we want to have a
> call for this?
>
> In addition to this issue, Alexander raised the issue that
> f:insertFacet and f:renderFacet are confusing. Not sure if there's
> anything we can do resolve this at this point, but minimally, it would
> be worth ensuring the EG members understand the difference (which IMO,
> is huge). In hindsight, f:insertFacet probably should have been
> f:attachFacet, and of course had an optional "target" attribute for
> Andy's case.
>
> Ken
>
> Andy Schwartz wrote:
>> Thanks Ed -
>>
>> Ed Burns wrote:
>>>
>>> I happen to prefer #1, but everyone else favors #2, we'll go with #2.
>>>
>>
>> Seems like some people prefer #2 as well, so perhaps this needs more
>> discussion.
>>
>>> Andy, can you please file a spec issue and share the number with the
>>> group? Once you have it, I'll add an entry in the changelog wiki.
>>>
>>>
>>
>> Sorry for taking so long to follow up on this. I have logged the
>> following spec issue:
>>
>> <A HREF="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=631">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=631</A>
>>
>>
>> Andy
>>
>>
</PRE>
</BLOCKQUOTE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
--<BR>
<B>Lincoln Baxter, III</B><BR>
Co-Founder of <A HREF="http://ocpsoft.com">OcpSoft</A><BR>
<BR>
Creator of:<BR>
<A HREF="http://ocpsoft.com/prettyfaces">PrettyFaces</A>: URL rewriting for JSF<BR>
<A HREF="http://ocpsoft.com/prettytime">PrettyTime</A>: Java elapsed timestamp formatting<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>