<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 10/6/10 12:38 PM, Leonardo Uribe wrote:
<blockquote
cite="mid:AANLkTinJwzwWZnJ4qT9=0_DEmXYyO32kKw8cpoddJKA7@mail.gmail.com"
type="cite"><br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> On 10/6/10 12:01 PM,
Leonardo Uribe wrote:
<blockquote type="cite"><br>
<br>
<div class="gmail_quote">2010/10/6 Blake Sullivan <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:blake.sullivan@oracle.com"
target="_blank">blake.sullivan@oracle.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> On 10/6/10
11:35 AM, Leonardo Uribe wrote:
<blockquote type="cite">Hi<br>
<br>
In theory, shouldn't the vdl be responsible to
indicate which prefix/suffix pattern is used to
identify if a physical viewId should be handled by
an specific vdl?.</blockquote>
No. While the VDL may have a preferred extension,
the authors should be free to route whatever content
they want to the VDL. For example, in the
particular case of running JSPX content through
Facelets, .jspx would not be a preferred mapping for
Facelets.<br>
<br>
</div>
</blockquote>
<div><br>
Ok, I see, that is for backward compatibility with
apps that uses JSPX content for jsp. But in such case,
which one is responsible to define such mapping?. Note
right now it is not possible to create another vdl
without break RestoreView algorithm. In theory, the
ViewDeclarationLanguageFactory should do it (I did
some attempts on this issue and finally I added some
methods there).<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div> </div>
</div>
2010/10/6 Blake Sullivan <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:blake.sullivan@oracle.com">blake.sullivan@oracle.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> If a particular JAR
contains .jspx content that it wants to run through the
facelets engine in a compatibility mode, that JAR would
contain the mapping in its faces-config.xml and an application
using that JAR wouldn't have to concern itself with that
implementation detail.<br>
<br>
</div>
</blockquote>
<br>
But note this implementation detail is made explicit on the JAR,
but the implementation proposed is just a workaround for facelets
vdl. Let's take a look at how it is described on faces-config.xml<br>
<br>
<faces-config-extension><br>
<facelets-processing><br>
<file-extension>.jspx</file-extension><br>
<div id=":n"> <process-as>jspx</process-as><br>
</facelets-processing><br>
<facelets-processing><br>
<file-extension>.view.xml</file-extension><br>
<process-as>xml</process-as><br>
</facelets-processing><br>
</faces-config-extension><br>
<br>
</div>
From my point of view it says: "...for facelets vdl, if .jspx
extension is found on the physical resource file, process it as
some specific 'mode', and if .view.xml extension is found on the
physical resource file, process it as xml...".<br>
<br>
</blockquote>
Yep<br>
<blockquote
cite="mid:AANLkTinJwzwWZnJ4qT9=0_DEmXYyO32kKw8cpoddJKA7@mail.gmail.com"
type="cite">
<br>
Does that suggest a vdl can process a file in different "modes"?
Maybe yes, there could be some difference about how should be
processed from facelets vld.<br>
</blockquote>
Since this is a facelets-specific extension, facelets can do
whatever it wants with it<br>
<blockquote
cite="mid:AANLkTinJwzwWZnJ4qT9=0_DEmXYyO32kKw8cpoddJKA7@mail.gmail.com"
type="cite"><br>
Now suppose the .jspx files are in some directory inside the JAR.
How facelets can found them? ... through a custom
javax.faces.view.facelets.ResourceResolver implementation ... Can
we configure this artifact from faces-config.xml?.... no .... If
we configure ResourceResolver interface that will work? .... no
because the algorithm on RestoreView is very specific on that
field and does not take into account ResourceResolver to find
resources.<br>
</blockquote>
Are you talking about needing a custom way of coughing up resources,
or that the scheme for finding resources needs to know about the VDL
in some way? In the JAR case, it doesn't care about the VDL at all,
it is simply loading the requested resources out of the JAR
regardless of extension.<br>
<blockquote
cite="mid:AANLkTinJwzwWZnJ4qT9=0_DEmXYyO32kKw8cpoddJKA7@mail.gmail.com"
type="cite">
<br>
Things are different if we take as target files inside
META-INF/resources (composite components). No ResourceResolver
instance is involved and there will be no problem from RestoreView
algorithm (because those files will not be used for create views).<br>
<br>
In few words, my concern with this one is if this is being solved,
why don't do it in a more standard way for all vdl and solve all
those holes in the spec once for all?<br>
</blockquote>
I agree that the resource loading scheme in JSF is weak and can be
improved and that can be done with or without this enhancement. We
could also later generalize the registration for other VDLs, but the
fact that we would need to support options would make this much more
complicated, so I question whether the effort and complexity would
be worth it without further examples.<br>
<br>
-- Blake Sullivan<br>
<br>
<blockquote
cite="mid:AANLkTinJwzwWZnJ4qT9=0_DEmXYyO32kKw8cpoddJKA7@mail.gmail.com"
type="cite"><br>
Leonardo Uribe<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>