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