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

[Ed Burns]

On Thu, Sep 30, 2010 at 11:22 PM, Edward Burns <edward.burns at oracle.com>wrote:

EB> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=490

EB> As a first step towards making JSPX files runable as Facelets, this
EB> commit introduces a new configuration syntax.

>>>>> On Wed, 06 Oct 2010 11:35:24 -0400, Kito Mann <kito.mann at virtua.com> said:

KM> So I think we should implement this as a standard web.xml context
KM> parameter, _or_ provide faces-config.xml support for all existing
KM> context parameters.

>>>>> On Wed, 06 Oct 2010 10:50:39 -0700, Blake Sullivan <blake.sullivan at oracle.com> said:

B> It isn't that these parameters are newer, it is that these parameters 
B> potentially need to be configurable on a per-JAR level and we want the 
B> JAR to ship with its configuration.

>>>>> On Wed, 06 Oct 2010 13:35:39 -0500, Leonardo Uribe <lu4242 at gmail.com> said:

LU> In theory, shouldn't the vdl be responsible to indicate which
LU> prefix/suffix pattern is used to identify if a physical viewId
LU> should be handled by an specific vdl?. In my personal opinion it is
LU> more important to define some methods on vdl that handle this
LU> interaction properly and update the spec in that direction. That's
LU> the missing part of the puzzle.

>>>>> On Wed, 06 Oct 2010 11:46:00 -0700, Blake Sullivan <blake.sullivan at oracle.com> said:

B> No.  While the VDL may have a preferred extension, the authors should be 
B> free to route whatever content they want to the VDL.  For example, in 
B> the particular case of running JSPX content through Facelets, .jspx 
B> would not be a preferred mapping for Facelets.

>>>>> On Wed, 6 Oct 2010 14:03:02 -0500, Leonardo Uribe <lu4242 at gmail.com> said:

LU> Ok, I see, that is for backward compatibility with apps that uses JSPX
LU> content for jsp. But in such case, which one is responsible to define such
LU> mapping?. Note right now it is not possible to create another vdl without
LU> break RestoreView algorithm. In theory, the ViewDeclarationLanguageFactory
LU> should do it (I did some attempts on this issue and finally I added some
LU> methods there).

Leonardo, I am very interested in seeing the methods you had to add.  I
expect that the problem you solved by adding them is closely related to
the problem Andy wants to solve with [490-XmlViews], namely, provide
some way to advise the runtime how to process facelet files.  Closely
related, but maybe not identical. Perhaps using Dan's [490-XmlViews]
issue to contain this feature was a mistake.

>>>>> On Wed, 6 Oct 2010 14:38:41 -0500, Leonardo Uribe <lu4242 at gmail.com> said:

LU> But note this implementation detail is made explicit on the JAR, but the
LU> implementation proposed is just a workaround for facelets vdl. Let's take a
LU> look at how it is described on faces-config.xml

LU>  <faces-config-extension>
LU>    <facelets-processing>
LU>      <file-extension>.jspx</file-extension>
LU>      <process-as>jspx</process-as>
LU>    </facelets-processing>
LU>    <facelets-processing>
LU>      <file-extension>.view.xml</file-extension>
LU>      <process-as>xml</process-as>
LU>    </facelets-processing>
LU>  </faces-config-extension>

LU> From my point of view it says: "...for facelets vdl, if .jspx
LU> extension is found on the physical resource file, process it as some
LU> specific 'mode', and if .view.xml extension is found on the physical
LU> resource file, process it as xml...".

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 facelets
LU> vld.

Yes, that's correct.

Ed

-- 
| edward.burns at oracle.com | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/