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

[Andy Schwartz]

On 10/18/10 4:43 PM, Leonardo Uribe wrote:
> Hi
>
> 2010/10/18 Andy Schwartz <andy.schwartz at oracle.com 
> <mailto:andy.schwartz at oracle.com>>
>
>
>
>     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.
>
>  
> 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.

Great, thanks Leonardo.

I have attached a patch to issue 893 that implements these changes.  See:

https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachment.cgi/313/alternate-fix-893-take2.patch

Note that this is very similar to the approach that you took in your 
patch, but with some of the changes that we have discussed in this thread.

We'll need to review the following new APIs:

1. ViewHandler.deriveLogicalViewId()

We've got two options here:

- Add an overload of deriveViewId() that takes a boolean to indicate 
whether or not to test for a physical resource. Or...
- Pick a new method name.

I went for the latter approach:

>     /**
>      * <p class="changed_added_2_1">Derive and return the viewId from
>      * the current request, or the argument input by following the
>      * algorithm defined in specification section JSF.7.5.2.  Note that
>      * unlike <code>deriveViewId()</code>, this method does not 
> require that
>      * a physical view be present.</p>
>      *
>      * <p>The default implementation of this method simply returns
>      * rawViewId unchanged.</p>
>      *
>      * @param context the <code>FacesContext</code> for this request
>      *
>      * @param rawViewId the <code>viewId</code> to derive,
>      *
>      * @since 2.1
>      */
>     public String deriveLogicalViewId(FacesContext context, String 
> rawViewId) {

We can revisit this decision if folks do not like this.

2.  ViewDeclarationLanguage.viewExists()

>     /**
>      * <p class="changed_added_2_1">Tests whether a physical resource
>      * corresponding to the specified viewId exists.</p>
>      *
>      * <p>The default implementation uses
>      * <code>ExternalContext.getResource()</code> to locate the physical
>      * resource.</p>
>      *
>      * @param context The <code>FacesContext</code> for this request.
>      * @param viewId the view id to test
>      *
>      * @since 2.1
>      */    
>     public boolean viewExists(FacesContext context,
>                               String viewId) {

Note that I did not add any new methods to 
ViewDeclarationLanguageFactory.  Code that needs to check for existence 
can simply grab the VDL and perform the test.

3.  ViewDeclarationLanguage.getId()

>     /**
>      * <p class="changed_added_2_1">Returns a non-null String that can be
>      * used to identify this view declaration language.</p>
>      *
>      * <p>The default implementation returns the empty string.  Subclasses
>      * should override to return an id that uniquely identifies the
>      * view declaration language implementation.</p>
>      *
>      * @since 2.1
>      */
>     public String getId() {
>

Nothing too exciting here.  I suppose this could have been abstract, but 
figured a default implementation that returns the empty string would be 
acceptable.

4. ViewDeclarationLanguage id constants

>     /**
>      * <p class="changed_added_2_0">Identifier for the JSP view 
> declaration
>      * language.</p>
>      *
>      * @since 2.1
>      */
>     public final static String JSP_VIEW_DECLARATION_LANGUAGE_ID =
>         "java.faces.JSP";
>
>     /**
>      * <p class="changed_added_2_0">Identifier for the Facelets view
>      * declaration language.</p>
>      *
>      * @since 2.1
>      */
>     public final static String FACELETS_VIEW_DECLARATION_LANGUAGE_ID =
>         "java.faces.Facelets";

Thoughts?

Andy