3:43 p.m.
Hi
2010/10/18 Andy Schwartz <andy.schwartz(a)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/showattachm...
>
> - Solution enhanced that delegate extension configuration to VDL
>
>
>
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
>
> 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