Re: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets

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