Hi Leonardo,
Am 07.11.2012 um 20:17 schrieb Leonardo Uribe <lu4242_at_gmail.com>:
>> I think the FacesContext can represent any scope, because it has any information it needs to decide about the prefixes:
>>
>> - use getExternalContext().getRequest() to make it request scoped
>> - use getExternalContext().getSession(true) to make it session scoped
>> - use getViewRoot() to make it view scoped
>> - use nothing to make it application scoped
>>
>> We can support both with a default implementation like
>>
>> FacesContext.getResourcePrefixes() {
>> return getViewRoot().getResourcePrefixes();
>> }
>>
>
> In my understanding, FacesContext is a "helper" object, more than an
> object that
> represent a scope. That does not change the relationship between the view, and
> the multi-template configuration. Take a look at JSF 2.2 spec section 7.7.2.1
> ViewDeclarationLanguage.createView() :
>
> "... The createView() method must fulfill the following responsibilities.
>
> All implementations must:
>
> If there is an existing UIViewRoot available on the FacesContext, this method
> must copy its locale and renderKitId to this new view root. If not, this method
> must call calculateLocale() and calculateRenderKitId(), and store the results
> as the values of the locale and renderKitId, proeprties, respectively, of the
> newly created UIViewRoot. If no viewId could be identified, or the viewId is
> exactly equal to the servlet mapping, send the response error
> code SC_NOT_FOUND with a suitable message to the client. ..."
>
> In the case of multi-template configuration, the same step as with locale or
> renderKitId should be done: calculate it and store the values in the view. The
> multi-template configuration must be saved and restored with the view
> information.
> This ensures the view will be restored properly, because the calculation step
> is done when the view is built by first time.
>
> I have been working for a long time on Partial State Saving algorithm,
> and something that I discover doing a lot of tests was that to ensure the state
> works correctly, it is absolutely necessary when restore the view to build the
> view in the same way it was built by first time. The only way to do that, is
> ensure all information related to the view is available before build the view
> using facelets algorithm, and modify facelets algorithm to use that
> information when building the view.
>
> In few words, the multi-template configuration is a parameter of the view.
Ok. But we must expose it somehow so that the resource handler can pick it up. That's why I wanted it on the FacesContext. We should simply enforce that FacesContext.getResourcePrefixes() returns the same result once it's calculated.
>>>> LU> <ui:insert name="contractB:header"/>
>>>>
>>>> Manfred suggested an additional attribute "template". In this case,
>>>> this would be <ui:insert template="contractB" name="header" />.
>>
>> Isn't this implicitly given by the chosen template? Suppose you have:
>>
>> /contractA/template.xhtml:
>>
>> <html>
>> <body>
>> <div>left</div>
>> <ui:insert name="right"/>
>> </body>
>> </html>
>>
>> /contractB/template.xhtml:
>>
>> <html>
>> <body>
>> <ui:insert name="left"/>
>> <div>left</div>
>> </body>
>> </html>
>>
>> /home.xhtml:
>>
>> <ui:composition template="/template.xhtml>
>> <ui:define name="left">something on the left</ui:define>
>> <ui:define name="right">something on the right</ui:define>
>> </ui:composition>
>>
>> So if contractA is chosen, "something on the right" gets inserted, if contractB is chosen, "something on the left" gets inserted.
>>
>> One could also define /contractC/template.xhtml:
>>
>> <html>
>> <body>
>> <ui:insert name="left"/>
>> <ui:insert name="right"/>
>> </body>
>> </html>
>>
>> Where both get inserted.
>>
>
> In my understanding the attribute "template" is just optional in those
> rare cases
> where the names used for each template are not mutually exclusive. I
> think it has
> sense because the page author must be aware of the multi-template
> contracts used
> by the view (but he/she should not know anything about the
> implementation). Since
> the multi-template contract is defined by a third-party, the page
> author cannot change
> the names once defined, so he/she needs a lifesaver in these cases.
I still don't get it. From my point of view the page author is defines the contract like this:
I have a template.xhtml which should insert a,b,c. I have also some graphics a.png, b.png and c.png. I have also a footer.xhtml. The multi-template provider can override them all.
Ciao Frank