[jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Leonardo Uribe
lu4242 at gmail.com
Mon Oct 18 16:43:17 EDT 2010
Hi
2010/10/18 Andy Schwartz <andy.schwartz at 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> <!-- 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.
>
>
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> <!-- 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.
>
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20101018/fcde8c6a/attachment-0002.html
More information about the jsr-314-open-mirror
mailing list