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

Blake Sullivan blake.sullivan at oracle.com
Wed Oct 20 22:01:23 EDT 2010


  For ViewDeclarationLanguage.getId(), why don't we use the fully 
qualified classname as the default implementation?

-- Blake Sullivan

On 10/20/10 3:32 PM, Andy Schwartz wrote:
> 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
>




More information about the jsr-314-open-mirror mailing list