>>>>> 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?
ACTION: Can we get away with just doing multi-template-zero-config for
JSF 2.2?
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?
ACTION: Do we need multi-template-per-application-config?
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" />.
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.
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/