Hi
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.
>
>>>>>> 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. 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).
In conclusion, I don't think that multi-template-zero-config as described before
is not acceptable. What can be done, is delegate the responsibility from the
ViewHandler to the VDL, and allow override that class (the VDL is responsible
to decide which files can handle and how to do it). One option is
allow different
levels of configuration, one at application scope (ViewHandler/VDL), one at view
scope and so on. I think it is easier for users to setup using an EL expression
in f:view + an application scope bean, and a pattern matching mechanism using
web config params.
> ACTION: Can we get away with just doing multi-template-zero-config for
> JSF 2.2?
>
Unfortunately in my opinion, no.
> If not, my colleague Manfred Riem did some thinking about this and
> suggested "templates" as the attribute name on <f:view>. Let's call
> this multi-template-per-view-config. The last config case is called
> multi-template-per-application-config. Manfred also suggested a nice
> config scheme for this which I will share if we think zero-config and
> per-view-config is insufficient.
>
> ACTION: Do we need multi-template-per-view-config?
>
+1 (non binding, because only EG members can vote for this)
> ACTION: Do we need multi-template-per-application-config?
>
+1 (non binding, because only EG members can vote for this)
> LU> Nothing special until this moment. The order defines the priority to
> LU> resolve the templates and scan for resources. This approach does not
> LU> exclude the use a web config param for this one, and it is enough simple
> LU> to understand. In UIViewRoot, we can add a map, so the key is the
> LU> contract name (or library name) and the value is the implementation to
> LU> use (or resource prefix).
>
> Yes, this is necessary whatever config solution we adopt
>
> 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" />.
>
Sounds good to me.
> LU> I don't know if it is possible to define views inside a
> LU> multi-template. If that so, it could be good to discuss how it works,
> LU> and if resources inside a multi-template count as files appended to the
> LU> request path (like defined in the webapp folder).
>
> I would like to exclude that.
>
No objections from my side. I can't imagine an use case right now that
requires a
multi-template contract to define a view, but I feel that at least we
should take a look
at how things work joining all pieces together (faces-flow and
multi-templating).
Nothing to worry about for now.
> LU> EB >> Do you see any
> LU> EB >> problems in the current state of the reduced scope option that would
> LU> EB >> close the door to a more full proposal later?
>
> LU> With the changes proposed here and polishing the details, theorically I
> LU> don't see any problem.
>
> I need some others to weigh in!
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/