[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