Hi All,
Am 07.11.2012 um 02:25 schrieb Leonardo Uribe <lu4242_at_gmail.com>:
> 2012/11/6 Edward Burns <edward.burns_at_oracle.com>:
>>>>>>> On Sun, 4 Nov 2012 20:32:46 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
>> LU> Basically, the discussion about how this feature should looks like
>> LU> is about these three points. The position of the EG about them will
>> LU> decide the final result. Personally, I'm willing to support full
>> LU> multi-templating proposal, because I believe it is possible to
>> LU> design an intermediate solution, but at the end is up to the members
>> LU> of the EG to decide which route should be taken.
>>
>>>>>>> On Mon, 5 Nov 2012 16:29:37 +0100, Frank Caputo <frank_at_frankcaputo.de> said:
>>
>> FC> I think having more than one contract is hard to maintain.
>>
>> Ok, this is something I am going to decide right now: zero, one, or
>> more-than-one. We need more-than-one. There you have it.
>>
>> The feature is called *multi* templating, after all.
OK. But I'm still a little bit confused, how multiple contracts should be used in ONE request?
>>
>>>>>>> On Mon, 5 Nov 2012 14:31:01 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
>> LU> What do we need to support multiple multi-template contracts?
>>
>> LU> Instead of a single value, we should define a list of values, in
>> LU> this case, a list of libraryNames that identify each multi-template
>> LU> contract to apply on the view, maybe separated by comma. For
>> LU> example:
>>
>> LU> <faces-config ....>
>> LU> <application>
>> LU> <default-multi-template-contract>contractA:impl1,
>> LU> contractB:impl2</default-multi-template-contract>
>> LU> </application>
>> LU> </faces-config>
>>
>> LU> or
>>
>> LU> <f:view multiTemplateContract="contractA:impl1, contractB:impl2"/>
>>
>> Both of these answer the question, "How does Page Author indicate that
>> their pages should be influenced by a multi-template?"
>>
>> Frank's original reduced scope idea was to have a property on the
>> FacesContext. We could keep that idea and make the property be able to
>> return a list of resource prefixes. Frank's idea, call it
>> multi-template-zero-config for discussion, was for the spec to say
>> nothing about how this property was to be set. In practice, he felt
>> that people could decorate the FacesContextFactory to set it.
>>
>> Is that acceptable?
>
> Isn't better use a EL expression bound to a bean than override FacesContext?
> The problem is conceptually speaking, FacesContext has "request scope" ,
> but this is a "view scope" value.
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();
}
> Suppose a view that has a multi-template
> contract implementation applied and you change the implementation in a
> POST. The view becomes unstable and that will lead to exceptions. The same
> happens when you change the locale and you use a localized composite
> component, or when you change the renderkit (because components added
> using @ResourceDependency annotation depends on the renderer classes).
Sure, the prefixes must not change during the request.
>> ACTION: Can we get away with just doing multi-template-zero-config for
>> JSF 2.2?
I still think so.
>> LU> Now, suppose both contracts implement "header" definition. In this case,
>> LU> the header defined in contractA will be resolved first, but to get the
>> LU> one in contractB we can just change a little bit the syntax to allow
>> LU> something like this:
>>
>> 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.
>> I need some others to weigh in!
This would be cool.
Ciao Frank
-
Frank Caputo
Johann-Mohr-Weg 24d
22763 Hamburg
Mobil +49 177 61 61 81 3
E-Mail info_at_frankcaputo.de