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

[Ed Burns]

Summary:

After independent readings of the thread, Andy and I came to the same
conclusion: the discussion went beyond the intent of the original
proposal.

ACTION: The proposal still stands as it is, unmodified.  Please read
inline for justification for this action.

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 Mon, 11 Oct 2010 16:01:25 -0400, Andy Schwartz <andy.schwartz at oracle.com> said:

AS> It seems like we are now back to the original topic/proposal - ie. 
AS> whether it makes sense to allow Facelets-specific processing behavior to 
AS> be controlled on a per-jar basis (META-INF/faces-config.xml) or whether 
AS> this should be handled at the application level (web.xml).  Originally 
AS> Blake and I were thinking that jar-level configuration would be useful - 
AS> ie. it would allow this behavior to be controlled in a local manner.  
AS> However, given the typical manner in which faces-config.xml files are 
AS> merged into application-wide values, perhaps there is a mismatch here.

This is a good point.  The setting is, in fact, a per-application
setting.  The new jar ordering facility in 2.0 would decide who would
win when multiple jars with conflicting settings are encountered.  As
currently implemented, the last jar processed is the one whose settings
take precedence.

AS> If folks would prefer an web.xml/context parameter approach, I am open 
AS> to revisiting this.  The main requirement that I was hoping to meet is 
AS> the ability to control Facelets processing behavior (CDATA, XML 
AS> instruction handling, etc...) on a per-extension basis, including 
AS> support for custom extensions.

I honestly still think the faces-config-extension based configuration is
much more suitable here than an init-param based one.  This feature
calls for a mapping data structure that allows us to discover the
processing mode to be used given a physical resource file extension.
Defining this information in init-params would be ungainly.  

I rule that we keep the faces-config-extension syntax, and in the spec
language, which certainly will be written, I'll make sure to mention the
importance of ordering.

>>>>> 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.  

LU> Isn't that change confusing? What is worst, the spec pdf should be 
LU> changed too. Conclusion: the
LU> current strategy to handle suffix is insuficient.

AS> Of course we'll need to keep the spec pdf in sync with any changes that 
AS> we make.  Hopefully this is easily addressed.

Certainly.  I wanted to share the proposal in text form before putting
it in the spec document.  

LU> I'm still convinced that the vdl is responsible to indicate which 
LU> prefix/suffix pattern is used
LU> to identify if a physical viewId should be handled by that vdl.

AS> The Mojarra ViewDeclarationFactory implementation uses an approach like 
AS> this under the covers - ie. it asks each VDL whether it is capable of 
AS> handling a particular viewId until it finds a match.  In the Facelets 
AS> case, the answer to this question is driven by the context parameters 
AS> described above.  It sounds like you would like to see this approach 
AS> generalized and included in the public API.  Seems reasonable to me.

Leonardo, are do the methods you added to VDL address this feature?

AS> (i)  How viewIds are mapped to VDLs.
AS> (ii)  In the specific case of views that are mapped to the Facelets VDL, 
AS> how the Facelets engine processes views (eg. treatment of CDATA, XML 
AS> instructions, etc...)

AS> Ed's proposal wasn't intended to address any shortcomings in (i).  It 
AS> focuses on (ii).  We can certainly make improvements to (i) as well, 
AS> though these issues are not necessarily dependent on each other.

LU> Insist in simple hacks is deny the posibility to extend JSF to other
LU> vdls (don't get me wrong, my intention is contribute to JSF spec).

AS> Nothing about Ed's proposal denies the possibility to extend JSF to 
AS> other VDLs.  The proposal simply doesn't address this point.

To be fair, this is really Andy's idea which I've tried to refine into
an implementation and proposal.    

LU> 2. On any directory but it should be created a class that implements
LU> javax.faces.view.facelets.ResourceResolver, so it can get the resource 
LU> properly.
LU> Note the web config param "javax.faces.FACELETS_RESOURCE_RESOLVER" 
LU> does not
LU> work,

AS> In what way does this not work?  We are relying on ResourceResolver in 
AS> ADF Faces.  While the API doesn't address all of our requirements, the 
AS> ResourceResolver does seem to work as it always has.

Yes, I'm curious about this too.  Also, I want to point out another
issue that is on the 2.1 changelog: [777-FaceletCacheManagement].  This
is related to the ability to cache Facelet instances.

LU> and the interface ResourceResolver comes from facelets 1.1.x, so do
LU> not fix this issue breaks backward compatibility.

AS> What is the issue # for this problem?   Is this a Mojarra issue?  
AS> MyFaces?  Spec?  All of the above?

AS> This seems like a good thing to do.  Are you thinking that we'll add a 
AS> new hook on ViewDeclarationLanguage that allows the VDL implementation 
AS> to decide whether or not it can handle a particular view id?  Do we have 
AS> a spec issue logged for this topic?

Not that I know of.  I think we need one.

Ed

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