Hi<br><br><div class="gmail_quote">2010/10/18 Andy Schwartz <span dir="ltr"><<a href="mailto:andy.schwartz@oracle.com">andy.schwartz@oracle.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hey Leonardo -<br>
<br>
Backing up in the thread a bit...<div class="im"><br>
<br>
On 10/13/10 5:18 PM, Leonardo Uribe wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi<br>
<br>
For the problem related to ResourceResolver I created this issue:<br>
<br>
<a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=893" target="_blank">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=893</a><br>
<br>
And attached two patches:<br>
<br>
- Minimal proposal to fix ResourceResolver problem<br>
<br>
<a href="https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachment.cgi/307/fixResourceResolver-1.patch" target="_blank">https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachment.cgi/307/fixResourceResolver-1.patch</a><br>
<br>
- Solution enhanced that delegate extension configuration to VDL<br>
<br>
<a href="https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachment.cgi/308/fixResourceResolver-2.patch" target="_blank">https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachment.cgi/308/fixResourceResolver-2.patch</a><br>
<br>
>From the point of view of the spec the proposal is add this methods:<br>
<br>
</blockquote>
<br></div>
<snip><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
Looking the patch, you'll see more clear my intention. If solving these problems:<br>
<br>
1. Fix ResourceResolver.<br>
1.1 Fix getViewDeclarationLanguage() ambiguity.<br>
1.2 Fix section 7.5.2 to delegate the responsibility of file extension calculation to VDL,<br>
to allow other VDL work correctly.<br>
</blockquote>
<br></div>
Okay, I finally get it. :-)<br>
<br>
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.<br>
<br></blockquote><div><br>That's right.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
<br>
We should fix this.<br>
<br></blockquote><div><br>Yes.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Seems like the we could either:<br>
<br>
- Have the ViewDeclarationLangaugeFactory/ViewDeclarationLanguage cough up extensions for which they are configured. (Your recommendation).<br>
- Delegate deriveViewId() to ViewDeclarationLanguageFactory/ViewDeclarationLanguage.<br>
<br>
Either of these approaches would work for me.<br>
<br>
FWIW, this seems like a separate issue from the ResourceResolver issue - ie. these problems can be solved independently.<div class="im"><br></div></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
2. Fix suffix definition for vdls<br>
</blockquote>
<br></div>
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?<br>
<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Earlier you proposed exposing this sort of configuration in faces-config.xml, eg:<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<faces-config-extension><br>
<vdl-configuration><br>
<vdl-id>facelets</vdl-id><br>
<vdl-class>xxx.yyy.zzz.MyCustomFaceletsVDLWrapper</vdl-class><br>
<vdl-global-resource-mapping><br>
<br>
<file-extension>.jspx</file-extension><br>
<vdl-resource-mapping-config> <!-- Saved on key/value map or something like that --><br>
<br>
<process-as>jspx</process-as><br>
</vdl-resource-mapping-config><br>
</vdl-global-resource-mapping><br>
<vdl-global-resource-mapping><br>
<br>
<file-extension>.view.xml</file-extension><br>
<vdl-resource-mapping-config> <!-- Saved on key/value map or something like that --><br>
<br>
<process-as>xml</process-as><br>
</vdl-resource-mapping-config><br>
</vdl-global-resource-mapping><br>
</vdl-configuration><br>
</faces-config-extension><br>
</blockquote>
<br>
<br></div>
Presumably this would provide a generic way to:<br>
<br>
- Register new VDLs (instead of requiring context params like FACELETS_VIEW_MAPPINGS_PARAM_NAME)<br>
- Wrap existing VDLs<br>
- Map VDLs to specific file extensions (or possible prefixes?)<br>
- Specify VDL-specific parameters<br>
<br>
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.<br>
<br></blockquote><div><br>Sounds good. Maybe in this case we could have VDL registering inside <faces-config> tag like renderkit does:<br><br> <view-declaration-language><br>
<view-declaration-language-id>javax.faces.Jsp</view-declaration-language-id><br><div bgcolor="#ffffff" text="#000000">
<view-declaration-language-class>my.bizarre.vdl.WrapperForJspOnly</view-declaration-language-class><br>
</view-declaration-language></div><br>and VDL prefix/suffix mapping inside <faces-config-extension> tag.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Regarding:<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<vdl-resource-mapping-config> <!-- Saved on key/value map or something like that --><br>
<br>
<process-as>jspx</process-as><br>
</vdl-resource-mapping-config><br>
</blockquote>
<br></div>
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.<div class="im">
<br></div></blockquote><div><br>I was thinking on add a method on VDL called (maybe you can find a better name)<br><br> public void addResourceMapping(String fileExtension, Map<String,String> configurationMap)<br>
<br>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:<br><br> <config-param><br> <description>Some description</description><br>
<param-name>process-as</param-name><br> <param-value>jspx</param-value><br> </config-param><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
3. Fix specific suffix handling for facelets vdl<br>
<br>
It is resolved (1), easily it will point to 2. If we add the solution proposed for (1) with<br>
the solution proposed for (3), things are getting better, but if it is done an extra minimal<br>
effort on (2) based on the previous patches, the result will be even better.<br>
</blockquote>
<br></div>
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.<br>
<font color="#888888">
<br></font></blockquote><div><br>I think the list you did on a previous mail is very clear:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="im">
<br></div>
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.<br>
<br>
These seem to be the minimal requirements:<br>
<br>
1. The ViewHandler.getViewDeclarationLanguage() should be clear
that it
expects "derived" view ids.<br>
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.<br>
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.<br>
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.<br>
<br>
In addition, these requirements would be good to address:<br>
<br>
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.<br>
6. Allow #4 to be accomplished declaratively via faces-config.xml.<br>
<br>
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. :-)<br>
<br>
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.<br>
<br></div></blockquote><div> </div>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. <br>
<br>regards,<br><br>Leonardo Uribe<br></div></div><br>