[jsr-314-open-mirror] [jsr-314-open] Fwd: PostAddToViewEvent publishing conditions

[Martin Marinschek]

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