<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 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 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>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><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>
<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><br>Leonardo Uribe<br><br><br>