Hi Frank, Hi Ed
FC>> I think having more than one contract is hard to maintain.
Recently, I have been thinking that modify the reduced multi-template
proposal is
the way to go. With a careful implementation of "resource prefix"
concept, which is
a clever way to avoid some configuration burden, the only issue that I
see that can
be a problem in the future is allow just one multi-template contract.
Theorically, one problem I see is the view definition should be
self-contained, which
means all information related to build the view should be possible of
define inside
the view. For example, you can use f:view to define the "locale" or
the "renderKitId"
of the view using EL params or directly. If those variables are not
defined, there
are proper method in ViewHandler to calculate them:
public abstract Locale calculateLocale(FacesContext context);
public abstract String calculateRenderKitId(FacesContext context);
Multi-template concept should be defined in the same way. For example, you can
set the default renderKitId to be used in the views of the application
in this way:
<faces-config ....>
<application>
<default-render-kit-id>my.custom.RenderKitId</default-render-kit-id>
</application>
</faces-config>
But it is possible to do this too:
<f:view renderKitId="my.custom.RenderKitId">
"locale" concept has something similar too, and multi-template should follow the
same approach too.
What do we need to support multiple multi-template contracts? Instead a single
value, we should define a list of values, in this case, a list of
libraryNames that
identify each multi-template contract to apply on the view, maybe separated
by comma. For example:
<faces-config ....>
<application>
<default-multi-template-contract>contractA:impl1,
contractB:impl2</default-multi-template-contract>
</application>
</faces-config>
or
<f:view multiTemplateContract="contractA:impl1, contractB:impl2"/>
Nothing special until this moment. The order defines the priority to
resolve the
templates and scan for resources. This approach does not exclude use a
web config
param for this one, and at the end is enough simple to understand. In
UIViewRoot,
we can add a map, so the key is the contract name (or library name)
and the value
is the implementation to use (or resource prefix).
Now, suppose both contracts implement "header" definition. In this case, the
header defined in contractA will be resolved first, but to get the one
in contractB
we can just change a little bit the syntax to allow something like this:
<ui:insert name="contractB:header"/>
and problem solved. There will not be problems with resources, because the
libraryName by itself identify the multi-template, right?, so there is no need
to do any changes.
For implement "resource prefix" concept, we can just enable it only for
libraries which has a template.xhtml file, because it only has sense
for multi-template
aware libraries, and use a query param like with libraryName or locale.
I don't know if it is possible to define views inside a
multi-template. If that so, it could
be good to discuss how it works, and if resources inside a
multi-template count as
files appended to the request path (like defined in the webapp folder).
EB >> Do you see any
EB >> problems in the current state of the reduced scope option that would
EB >> close the door to a more full proposal later?
With the changes proposed here and polishing the details, theorically
I don't see any
problem.
regards,
Leonardo Uribe
2012/11/5 Frank Caputo <frank_at_frankcaputo.de>:
> Hi Leonardo,
>
> Am 05.11.2012 um 02:32 schrieb Leonardo Uribe <lu4242_at_gmail.com>:
>
>> - If multi-templating is an "application scope" concept (only one
>> multi-template
>> contract per application, but multiple implementations), the advantage is there
>> no need for any configuration about the relationship between a view and the
>> multi-template to apply for that view, but the disadvantage is it limits
>> reusability, because it is not possible to set multiple contracts in the same
>> application (for example one for layout, one for skinning and so on).
>
> I think having more than one contract is hard to maintain.
>
> Ciao Frank