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

[Blake Sullivan]

  On 10/6/10 12:38 PM, Leonardo Uribe wrote:
>
>     On 10/6/10 12:01 PM, Leonardo Uribe wrote:
>>
>>
>>     2010/10/6 Blake Sullivan <blake.sullivan at oracle.com
>>     <mailto:blake.sullivan at oracle.com>>
>>
>>         On 10/6/10 11:35 AM, Leonardo Uribe wrote:
>>>         Hi
>>>
>>>         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?.
>>         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.
>>
>>
>>     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).
>
> 2010/10/6 Blake Sullivan <blake.sullivan at oracle.com 
> <mailto:blake.sullivan at oracle.com>>
>
>     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.
>
>
> 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
>
> <faces-config-extension>
> <facelets-processing>
> <file-extension>.jspx</file-extension>
> <process-as>jspx</process-as>
> </facelets-processing>
> <facelets-processing>
> <file-extension>.view.xml</file-extension>
> <process-as>xml</process-as>
> </facelets-processing>
> </faces-config-extension>
>
> 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...".
>
Yep
>
> 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.
Since this is a facelets-specific extension, facelets can do whatever it 
wants with it
>
> 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.
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.
>
> 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).
>
> 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?
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.

-- Blake Sullivan

>
> Leonardo Uribe
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20101006/32141cc6/attachment-0002.html