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
