jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: [1142-ResourceLibraryContracts] config options: property name, time and location (was: [971-MultiTemplate])

From: Leonardo Uribe <lu4242_at_gmail.com>
Date: Mon, 12 Nov 2012 13:23:35 -0500

Hi

2012/11/10 Frank Caputo <frank_at_frankcaputo.de>:
>
> Am 09.11.2012 um 23:11 schrieb Edward Burns <edward.burns_at_oracle.com>:
>
>> CONDITIONALLY_RESOLVED: The name of the property is
>> resourceLibraryContracts. I considered resourceContracts but really the
>> feature is a library contract, not just a resource contract.
>
> OK.
>

+1

>> CONDITIONALLY_RESOLVED: Define a read-only property located on
>> UIViewRoot whose type is List<String>. Specify that if it is not set,
>> it must return an empty List. This property is accessible by doing
>> FacesContext.getViewRoot().getResourceLibraryContracts().
>
> OK.
>

+1. Just remember each string should have the following structure:

[contract-library-name]:[contract-resource-prefix]

For example

my.custom.resourceLibraryContract:implA

and so on.

>> LU> In few words, the multi-template configuration is a parameter of the view.
>>
>> I agree. Rather than introduce a new property on FacesContext, it is a
>> new property on the UIViewRoot. Let's introduce a new method
>> calculateResourceLibraryContracts(). Where should this method live?
>> The other calculate*() methods live on ViewHandler. Our new
>> calculateResourceLibraryContracts() is specific to the VDL, so it should
>> live on the VDL. Note that we lose the ability to define the contracts
>> on the <f:view> in this way because we will not have even loaded the XML
>> file that gives us the Facelet. I am fine with this loss.
>>
>> CONDITIONALLY_RESOLVED: Add new method on VDL,
>> calculateResourceLibraryContracts(). This email doesn't say what this
>> method does other than returning List<String> of the resource contracts.
>
> You can't obtain the VDL without a viewId. But you might need to be able to calculate it without a viewId. MyFaces' ResourceHandlerImpl can calculate the locale prefix without a view. So let's use the same behavior and put the new method on the ViewHandler.
>

+1 to use ViewHandler. Even if some VDL does not implement this feature, it
is clearly a view related concept.

>> LU> Consider a view that has a multi-template contract implementation
>> LU> applied and you change the implementation in a POST. The view
>> LU> becomes unstable and that will lead to exceptions. The same happens
>> LU> when you change the locale and you use a localized composite
>> LU> component, or when you change the renderkit (because components
>> LU> added using @ResourceDependency annotation depends on the renderer
>> LU> classes).
>>
>> We must disallow changing the value of contract property during request
>> processing. This is achieved by the property being read-only.
>>
>> FC> We should simply enforce that FacesContext.getResourceContracts()
>> FC> returns the same result once it's calculated.
>>
>> Yes, exactly, it's a read-only property.
>>
>> CONDITIONALLY_RESOLVED: Modify 7.7.2.1 createView() to require calling
>> VDL.calculateResourceLibraryContracts() so that the read-only
>> resourceLibraryContracts property is correctly set when the UIViewRoot is
>> returned from that method. As I said above, the impl of
>> calculateResourceLibraryContracts() is in another email. How you set the
>> property on UIViewRoot before returning it from createView() is an
>> implementation detail.
>
> OK.
>

If calculateResourceLibraryContracts(FacesContext) is defined in ViewHandler,
there is no reason to prevent resourceLibraryContracts to be defined using
f:view tag, but if it is not, we can allow it later if the need
arises. Please note if
it is not set using f:view, it is not possible to use EL to define it,
which in my
opinion it is very straighforward, given than locale can be set in this way too.

regards,

Leonardo

> Ciao Frank