On 10/6/10 12:01 PM, Leonardo Uribe wrote: > > > 2010/10/6 Blake Sullivan <blake.sullivan(a)oracle.com > <mailto:blake.sullivan@oracle.com>> > > On 10/6/10 11:35 AM, Leonardo Uribe wrote: >> Hi >> >> In theory, shouldn't the vdl be responsible to indicate >> which prefix/suffix pattern is used to identify if a >> physical viewId should be handled by an specific vdl?. > No. While the VDL may have a preferred extension, the > authors should be free to route whatever content they want to > the VDL. For example, in the particular case of running JSPX > content through Facelets, .jspx would not be a preferred > mapping for Facelets. > > > Ok, I see, that is for backward compatibility with apps that uses > JSPX content for jsp. But in such case, which one is responsible > to define such mapping?. Note right now it is not possible to > create another vdl without break RestoreView algorithm. In > theory, the ViewDeclarationLanguageFactory should do it (I did > some attempts on this issue and finally I added some methods there). 2010/10/6 Blake Sullivan <blake.sullivan(a)oracle.com <mailto:blake.sullivan@oracle.com>> If a particular JAR contains .jspx content that it wants to run through the facelets engine in a compatibility mode, that JAR would contain the mapping in its faces-config.xml and an application using that JAR wouldn't have to concern itself with that implementation detail. But note this implementation detail is made explicit on the JAR, but the implementation proposed is just a workaround for facelets vdl. Let's take a look at how it is described on faces-config.xml <faces-config-extension> <facelets-processing> <file-extension>.jspx</file-extension> <process-as>jspx</process-as> </facelets-processing> <facelets-processing> <file-extension>.view.xml</file-extension> <process-as>xml</process-as> </facelets-processing> </faces-config-extension> From my point of view it says: "...for facelets vdl, if .jspx extension is found on the physical resource file, process it as some specific 'mode', and if .view.xml extension is found on the physical resource file, process it as xml...".

Does that suggest a vdl can process a file in different "modes"? Maybe yes, there could be some difference about how should be processed from facelets vld.

Now suppose the .jspx files are in some directory inside the JAR. How facelets can found them? ... through a custom javax.faces.view.facelets.ResourceResolver implementation ... Can we configure this artifact from faces-config.xml?.... no .... If we configure ResourceResolver interface that will work? .... no because the algorithm on RestoreView is very specific on that field and does not take into account ResourceResolver to find resources.

Things are different if we take as target files inside META-INF/resources (composite components). No ResourceResolver instance is involved and there will be no problem from RestoreView algorithm (because those files will not be used for create views). In few words, my concern with this one is if this is being solved, why don't do it in a more standard way for all vdl and solve all those holes in the spec once for all?

Leonardo Uribe

Hi LU>>>> Does that suggest a vdl can process a file in different "modes"? Maybe yes, LU>>>> there could be some difference about how should be processed from LU>>>> facelets vld. BS>> Since this is a facelets-specific extension, facelets can do whatever it wants with it Totally true, but since facelets vdl is part of JSF, this behavior should be included on the spec. I think at least it is worth to take some time and think carefully if the proposal is enough or not. I found the tables that defines how each extension should be processed by facelets XML construct process-as mode ------------- --------------- xhtml xml jspx XML Declaration passed through consumed consumed Processing Instructions passed through consumed consumed CDATA passed through consumed consumed Inline text escaping escaped escaped not escaped Comments passed through consumed consumed Note for support the new view.xml extension right now on Mojarra trunk these constants were changed: ViewHandler.DEFAULT_SUFFIX = ".xhtml .view.xml .jsp" ViewHandler.DEFAULT_FACELETS_SUFFIX = ".xhtml" // Why this constant is not ".xhtml .view.xml" if // .view.xml will be handled by facelets? Isn't that change confusing? What is worst, the spec pdf should be changed too. Conclusion: the current strategy to handle suffix is insuficient. I'm still convinced that the vdl is responsible to indicate which prefix/suffix pattern is used to identify if a physical viewId should be handled by that vdl. The fact that jspx extension could be used by two different vdl (facelets and jsp) does not means that for an specific web application this shouldn't be configured in one way or another. It's more, the current proposal does not specify how this should be used when it is necessary to handle some resources with jspx extension by jsp vdl and others with jspx extension by facelets vdl. Insist in simple hacks is deny the posibility to extend JSF to other vdls (don't get me wrong, my intention is contribute to JSF spec). Ok, at this point I see that you are thinking in something different than I'm thinking of, so I'll resume my point of view (it could be a little redundant but I want to be clear on the argumentation): A JAR file could contain resources that could be used by facelets in two situations: 1. On META-INF/resources/[localePrefix/][libraryName/]resourceName. 2. On any directory but it should be created a class that implements javax.faces.view.facelets.ResourceResolver, so it can get the resource properly. Note the web config param "javax.faces.FACELETS_RESOURCE_RESOLVER" does not work, and the interface ResourceResolver comes from facelets 1.1.x, so do not fix this issue breaks backward compatibility. Well, if that argument is not too strong, what's the point of provide a param and a interface that by the same spec can't be used?. Note on this mailing list, it has been mentioned by other people that this issue should be fixed. I'm supposing this issue will be fixed. In case 1, the resource file is loaded through JSF Resource Handler API, but in case 2 it is loaded through ResourceResolver. BS>> Are you talking about needing a custom way of coughing up resources, BS>> or that the scheme for finding resources needs to know about the VDL in some BS>> way? I'm saying that ResourceResolver already provides a way to load resources for facelets VDL. In theory, the same prefix and extensions configured for the application applies for ResourceResolver as well. That means if a extension provided by ResourceResolver is not configured, the resource will not be loaded, because the physical viewId will not be recognized as valid. BS>> In the JAR case, it doesn't care about the VDL at all, it is simply BS>> loading the requested resources out of the JAR regardless of extension. So, what's the point about have this configuration on a JAR, if there will be no resources using such extensions inside it?. If all resources used by facelets are inside the WAR or in the webapp directory, shouldn't that param be configured on web.xml or only in faces config application resource (WEB-INF/faces-config.xml). It's more, if I have the xml configuration proposed on JAR META-INF/faces-config.xml, what someone could expect is the configuration applies to case 1 (composite component resource files), and not globally, which it is the intention. LU>>>> In few words, my concern with this one is if this is being solved, why don't LU>>>> do it in a more standard way for all vdl and solve all those holes LU>>>> in the spec once for all? BS>> I agree that the resource loading scheme in JSF is weak and can be improved BS>> and that can be done with or without this enhancement. We could also BS>> later generalize the registration for other VDLs, but the fact that we would BS>> need to support options would make this much more complicated, so I BS>> question whether the effort and complexity would be worth it without further examples. Well, really there are three problems: 1. Fix ResourceResolver 2. Fix suffix definition for vdls 3. Fix specific suffix handling for facelets vdl I don't have any decision power in this matter, but I can contribute my personal opinion (don't get me wrong if I'm too hard, my intention is make JSF spec even better). All three issues are related. All of them should be solved. Delaying these issues with partial hacks only makes things worst and even harder to understand. "....Easy to do, hard to correct... ...Keep things simple..." I'm willing to contribute with this issue doing some code if necessary. Suggestions are welcome. best regards, Leonardo Uribe