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

[Ganesh]

Hi,

If I'm getting this right Leo is proposing a more general approach to this configuration. I agree that the facelets-* elements are too specific here. Wouldn't it make sense to have *optional* VDL specific config files like facelets-config.xml, jsp-config.xml, and, if someone writes a swing based vdl swing-config.xml? VDL internal constants like ViewHandler.DEFAULT_SUFFIX and ViewHandler.DEFAULT_FACELETS_SUFFIX could serve as defaults (conventions) and the vdl-config.xmls would be able to override them. Facelets could then define a special file-extension/process-as structure in their facelets-config.xml, other VDLs could require other extensions.

Best regards,
Ganesh

Am 07.10.2010 07:14, schrieb 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

-- 
"There are two kinds of people in the world, those who believe there are two kinds of people and those who don't."
— Robert Benchley