7:58 p.m.
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.
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.
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.
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?
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.
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.
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.
Andy