[jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets

[Andy Schwartz]

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.

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.

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.

>
> 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?

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> <!-- Saved on key/value map 
> or something like that -->
>
>                 <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> <!-- Saved on key/value map 
> or something like that -->
>
>                 <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.

Regarding:

>             <vdl-resource-mapping-config> <!-- Saved on key/value map 
> or something like that -->
>
>                 <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.

>
> 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.

Andy