Hi Andy,
my 2cents (isn´t worth much in this discussion if I don´t look any
deeper into this ;)
Given that ui:decorate is a non-trimming ui:composition, why would
these
behave differently with respect to interaction with the TemplateClient? I
would think that both of these handlers should be calling pushClient().
I don´t see why ui:decorate should be different from ui:composition, either.
Also, the multi-level search strategy seems somewhat questionable to
me. A
template exposes a certain number of of names into which content could be
inserted. The consumer of the template leverages that contract and
specifies content to be inserted into some subset of those names. When
attempting to locate content to insert, why should the template look any
further up the stack than the nearest consumer (ie. the most recently pushed
TemplateClient)?
Well, templates are certainly hierarchical - does the nearest consumer
carry all information, or just the one which is defined in itself?
Seems like this should have been implemented as a simple stack
solution
where the most recent TemplateClient is always used to resolve insertions.
Of course, there may be perfectly fine reasons for why Facelets supports
extendClient() and performs multi-level searches to locate content to
insert. Just not clear what these reasons are.
Note that for composite components, we should not follow the Facelets
precedent here. If a composite component exposes a facet for insertion, we
should only look to immediate consumer of the composite component for
matches - ie. we should not be walking up the entire ancestor stack.
> 3) Why does InsertHandler call extendClient()() and why does it implement
> TemplateClient?
>
> Because ui:insert could expose a spot too, and it is resolved to there if
> no ui:define (exposed by ui:composition) with the name is exposed too.
Right, so I see that InsertHandler is implemented this way, but... why?
Seems silly to have ui:insert serve two entirely different purposes - ie.
to both identify an insertion point as well as to define content for
included templates. Why should ui:insert act both as a ui:insert *and* as
a ui:define? If a template author wants to pass content through from an
outer page to an inner/nested template, seems like the right way to
accomplish this would be to wrap the ui:insert inside of a ui:define.
Well, if you define a template, you use ui:insert to mark the spots
where content can be - and then you include default content right
away. Is it this which makes ui:insert a thing of both worlds?
best regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces