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

[Andy Schwartz]

Hey Leonardo -

Thanks for the comments.  There are a few different issues here.  Let me 
see if I understand them...

On 10/7/10 1:14 AM, Leonardo Uribe wrote:
>
> 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?

I had to take another look at the doc/code for the various context 
parameters in this area.  My understanding is:

- The "javax.faces.FACELETS_SUFFIX" context parameter specifies a single 
file extension that is mapped to the Facelets engine.  This defaults to 
the ViewHandler.DEFAULT_FACELETS_SUFFIX value (ie. ".xhtml").
- The "javax.faces.FACELETS_VIEW_MAPPINGS" context parameter allows 
multiple extensions/prefixes to be mapped to the Facelets engine.  This 
context parameter has no default value.

To be honest, it isn't clear to me why two context parameters were 
necessary, since it seems that FACES_VIEW_MAPPINGS is more general than 
FACELETS_SUFFIX, though I suppose we just inherited this from Facelets 1.x.

With the default values as specified above, .view.xml extensions will 
not not routed to the Facelets engine.  Instead, the application must 
explicitly specify this mapping via the FACELETS_VIEW_MAPPINGS context 
parameter.  If we want to embrace this new file extension more fully, we 
either need to:

- Enhance the DEFAULT_FACELETS_SUFFIX context parameter to allow it to 
support multiple values + change the default value to ".xhtml 
.view.xml".  Or...
- Specify a default value for the FACELETS_VIEW_MAPPINGS context parameter.

Either of these seem acceptable to me.



>
> Isn't that change confusing? What is worst, the spec pdf should be 
> changed too. Conclusion: the
> current strategy to handle suffix is insuficient.

Of course we'll need to keep the spec pdf in sync with any changes that 
we make.  Hopefully this is easily addressed.

>
> 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 Mojarra ViewDeclarationFactory implementation uses an approach like 
this under the covers - ie. it asks each VDL whether it is capable of 
handling a particular viewId until it finds a match.  In the Facelets 
case, the answer to this question is driven by the context parameters 
described above.  It sounds like you would like to see this approach 
generalized and included in the public API.  Seems reasonable to me.


> 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.

Actually, the current proposal doesn't make any changes to the mechanism 
that is used for mapping extensions to VDLs.  There are two separate 
topics here:

(i)  How viewIds are mapped to VDLs.
(ii)  In the specific case of views that are mapped to the Facelets VDL, 
how the Facelets engine processes views (eg. treatment of CDATA, XML 
instructions, etc...)

Ed's proposal wasn't intended to address any shortcomings in (i).  It 
focuses on (ii).  We can certainly make improvements to (i) as well, 
though these issues are not necessarily dependent on each other.

> 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).

Nothing about Ed's proposal denies the possibility to extend JSF to 
other VDLs.  The proposal simply doesn't address this point.

>
> Ok, at this point I see that you are thinking in something different 
> than I'm thinking of,

Yep.  We've got two different things here.

> 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,

In what way does this not work?  We are relying on ResourceResolver in 
ADF Faces.  While the API doesn't address all of our requirements, the 
ResourceResolver does seem to work as it always has.


> and the interface ResourceResolver comes from facelets 1.1.x, so do 
> not fix this
> issue breaks backward compatibility.

What is the issue # for this problem?   Is this a Mojarra issue?  
MyFaces?  Spec?  All of the above?

> 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?.

We are using it here.  Now I am getting worried that maybe our code is 
broken. :-)  Though Jason also blogged on this topic here:

http://blogs.steeplesoft.com/2010/05/putting-facelets-in-a-jar/

Which makes me think that this must be minimally working.


> 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.

Right.  So, Facelets only processes viewIds that are specified by the 
javax.faces.FACELETS_SUFFIX and javax.faces.FACELETS_VIEW_MAPPINGS 
context parameters.  It will use the ResourceResolver to load such 
views.  The ResourceResolver won't ever see viewIds that are not mapped 
to the Facelets VDL.  This seems reasonable to me.

>
> 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,

FWIW, we (ADF) do bundle view files into jars and extract these using 
the ResourceResolver API, so in theory we could benefit from 
jar-specific configuration.

> shouldn't that param be configured on
> web.xml or only in faces config application resource 
> (WEB-INF/faces-config.xml).

It seems like we are now back to the original topic/proposal - ie. 
whether it makes sense to allow Facelets-specific processing behavior to 
be controlled on a per-jar basis (META-INF/faces-config.xml) or whether 
this should be handled at the application level (web.xml).  Originally 
Blake and I were thinking that jar-level configuration would be useful - 
ie. it would allow this behavior to be controlled in a local manner.  
However, given the typical manner in which faces-config.xml files are 
merged into application-wide values, perhaps there is a mismatch here.

If folks would prefer an web.xml/context parameter approach, I am open 
to revisiting this.  The main requirement that I was hoping to meet is 
the ability to control Facelets processing behavior (CDATA, XML 
instruction handling, etc...) on a per-extension basis, including 
support for custom extensions.

>
> 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.

I don't completely follow this.  Could you explain?

>
> Well, really there are three problems:
>
> 1. Fix ResourceResolver

It this is broken, it definitely needs to be fixed.  We need more 
details on exactly what behavior is broken.


> 2. Fix suffix definition for vdls

This seems like a good thing to do.  Are you thinking that we'll add a 
new hook on ViewDeclarationLanguage that allows the VDL implementation 
to decide whether or not it can handle a particular view id?  Do we have 
a spec issue logged for this topic?

> 3. Fix specific suffix handling for facelets vdl

This is the area that I am especially interested in, as:

- This will allow us all to move away from the legacy world of Facelets 
== XHTML.  And...
- This will allow me to start moving my existing JSPX content over to 
Facelets.

>
> 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).

Leonardo - your thoughts are always welcome and appreciated and without 
a doubt are helping to make the spec better, so please keep speaking 
your mind!

>
> 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.

I agree that all three issues should be solved.  FWIW, I think that #3 
can be solved independently of #1 and #2.  I don't quite see why these 
issues should be tightly coupled.  I also don't think that the proposal 
to fix #3 is a hack, but if others think that it is, we of course need 
to resolve these concerns.

Andy


>
> "....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