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

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20101007/c2b4fee7/attachment-0002.html