2010/10/18 Andy Schwartz <andy.schwartz@oracle.com>

Hey Leonardo -

Backing up in the thread a bit...

On 10/13/10 5:18 PM, Leonardo Uribe wrote:

Hi

For the problem related to ResourceResolver I created this issue:

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=893

And attached two patches:

- Minimal proposal to fix ResourceResolver problem

https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachment.cgi/307/fixResourceResolver-1.patch

- Solution enhanced that delegate extension configuration to VDL

https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachment.cgi/308/fixResourceResolver-2.patch

>From the point of view of the spec the proposal is add this methods:

<snip>

Looking the patch, you'll see more clear my intention. If solving these problems:

1. Fix ResourceResolver.
1.1 Fix getViewDeclarationLanguage() ambiguity.
1.2 Fix section 7.5.2 to delegate the responsibility of file extension calculation to VDL,
to allow other VDL work correctly.

Okay, I finally get it. :-)

The problem with the behavior specified in 7.5.2 is that it provides special-case treatment for Facelets. Other VDLs that define their own extension mappings are simply out of luck. Non-Facelets VDL mappings won't be considered when deriving view ids.

That's right.

ViewHandler should be VDL-agnostic and should delegate to ViewDeclarationLanguageFactory/ViewDeclarationLanguage for any VDL-specific functionality. Requiring the ViewHandler implementation to have intimate knowledge of Facelets violates the desired separation of responsibilities.

We should fix this.

Yes.

Seems like the we could either:

- Have the ViewDeclarationLangaugeFactory/ViewDeclarationLanguage cough up extensions for which they are configured. (Your recommendation).
- Delegate deriveViewId() to ViewDeclarationLanguageFactory/ViewDeclarationLanguage.

Either of these approaches would work for me.

FWIW, this seems like a separate issue from the ResourceResolver issue - ie. these problems can be solved independently.

It seems, but note the algorithm required to deriveViewId() should call ResourceResolver to check for resources, specially when suffix mapping is used, so if it is necessary to change section 7.5.2 for each problem, it could be good to do both changes at once.

2. Fix suffix definition for vdls

Er... now I am getting confused. We've been dealing with various issues relating to suffix handling. Can you remind me which one this corresponds to? Is this providing a generic mechanism for registering VDLs by suffix instead of requiring each VDL to define its own context parameters?

Right now, we use web-config params to configure which resources will be processed by each VDL. Yes, the idea is provide a generic mechanism for registering VDLs by suffix. Additionally, that mechanism could provide special config params to handle each suffix when required.

Earlier you proposed exposing this sort of configuration in faces-config.xml, eg:

<faces-config-extension>
<vdl-configuration>
<vdl-id>facelets</vdl-id>
<vdl-class>xxx.yyy.zzz.MyCustomFaceletsVDLWrapper</vdl-class>
<vdl-global-resource-mapping>

<file-extension>.jspx</file-extension>
<vdl-resource-mapping-config> 

<process-as>jspx</process-as>
</vdl-resource-mapping-config>
</vdl-global-resource-mapping>
<vdl-global-resource-mapping>

<file-extension>.view.xml</file-extension>
<vdl-resource-mapping-config> 

<process-as>xml</process-as>
</vdl-resource-mapping-config>
</vdl-global-resource-mapping>
</vdl-configuration>
</faces-config-extension>

Presumably this would provide a generic way to:

- Register new VDLs (instead of requiring context params like FACELETS_VIEW_MAPPINGS_PARAM_NAME)
- Wrap existing VDLs
- Map VDLs to specific file extensions (or possible prefixes?)
- Specify VDL-specific parameters

I like this idea as it would definitely make life easier for VDL authors and for frameworks that need to wrap VDLs. However, we may want to break this up somewhat - eg. separate the configuration for registering a VDL from the configuration for mapping the VDL to a specific prefix/suffix, similar to how web.xml separates the <servlet> and <servlet-mapping> configuration.

Sounds good. Maybe in this case we could have VDL registering inside <faces-config> tag like renderkit does:

<view-declaration-language>
<view-declaration-language-id>javax.faces.Jsp</view-declaration-language-id>

<view-declaration-language-class>my.bizarre.vdl.WrapperForJspOnly</view-declaration-language-class>
</view-declaration-language>

and VDL prefix/suffix mapping inside <faces-config-extension> tag.

Regarding:

<vdl-resource-mapping-config> 

<process-as>jspx</process-as>
</vdl-resource-mapping-config>

Were you thinking that the VDL implementations would participate in the parsing/processing of this content? Without this, it seems like it would be difficult to have VDL-specific elements such as <process-as> - ie. we might need to resort to generic parameter (name/value) elements, similar to web.xml.

I was thinking on add a method on VDL called (maybe you can find a better name)

   public void addResourceMapping(String fileExtension, Map<String,String> configurationMap)

to call it when faces-config.xml were parsed and pass that information. Yes, maybe a syntax similar to web.xml could do the job better in this case:

    <config-param>
        <description>Some description</description>
        <param-name>process-as</param-name>
        <param-value>jspx</param-value>
    </config-param>

3. Fix specific suffix handling for facelets vdl

It is resolved (1), easily it will point to 2. If we add the solution proposed for (1) with
the solution proposed for (3), things are getting better, but if it is done an extra minimal
effort on (2) based on the previous patches, the result will be even better.

I am still a bit lost on the #s and the dependencies between these items. I think that we should focus on identifying which changes we minimally need to get into 2.1 in order to address the most fundamental issues without hindering our ability to build up fuller solutions in 2.2.

I think the list you did on a previous mail is very clear:

I would very much like to see much of this addressed for 2.1 as well. We've covered quite a bit of ground here. Let's recap what we are looking for.

These seem to be the minimal requirements:

1. The ViewHandler.getViewDeclarationLanguage() should be clear that it expects "derived" view ids.
2. We need some way to safely derive view ids from the restore view phase. This means that we either need to be able to use the existing ViewHandler.deriveViewId() without triggering TCK failures, or we need a new method on ViewHandler that performs the same functionality as deriveViewId() without requiring that the derived view id passes the existence check.
3. We need a method on ViewDeclarationLanguage for testing view existence, eg. viewExists(). We should use this instead of directly calling ExternalContext.getResource() when checking to see whether a viewId corresponds to a physical view.
4. We need some way to wrap a specific VDL (eg. the JSP VDL). The minimal solution would be to introduce a VDL id (eg. ViewDeclarationLanguage.getId()) and define standard ids for the JSP and Facelets VDLs.

In addition, these requirements would be good to address:

5. Generalize the ResourceResolver API so that it can be shared across VDLs. This would involve: creating a new version of this contract that lives outside of javax.faces.view.facelets, allowing resource resolvers to be declared in faces-config.xml, exposing an Application-level API for retrieving the ResourceResolver.
6. Allow #4 to be accomplished declaratively via faces-config.xml.

Did I miss anything? Or, I should say, did I miss anything from this branch of the discussion? I still need to go back and review some of the topics that I ignored from the original discussion. :-)

For me, #1-#4 are the key requirements that I would like to address in 2.1. #5 and #6 would be improvements that I would also welcome, but for my own needs I can get by if we have to defer these until 2.2.

Yes, I agree with you that #1-#4 are the minimal points that need to be address in 2.1. But I think personally that do #6 is better that include the patch proposed intially (facelets-processing), because after all, the code to make #6 work is not quite different, but if that's not possible the initial patch is ok. Anyway, I'll be happy if #1-#4 could be solved for 2.1.

regards,

Leonardo Uribe