Re: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
by Ed Burns
GP> If I'm getting this right Leo is proposing a more general approach
GP> to this configuration. I agree that the facelets-* elements are too
GP> specific here. Wouldn't it make sense to have *optional* VDL
GP> specific config files like facelets-config.xml, jsp-config.xml, and,
GP> if someone writes a swing based vdl swing-config.xml? VDL internal
GP> constants like ViewHandler.DEFAULT_SUFFIX and
GP> ViewHandler.DEFAULT_FACELETS_SUFFIX could serve as defaults
GP> (conventions) and the vdl-config.xmls would be able to override
GP> them. Facelets could then define a special file-extension/process-as
GP> structure in their facelets-config.xml, other VDLs could require
GP> other extensions.
I disagree. Rather than introduce new config files, which would be *so*
late 20th century, I like the idea of leveraging the
faces-config-extension mechanism built into the JSF config schema.
It would really be great if Dan could chime in here, but I am aware of
JBoss's position regarding not contributing without an active JSR.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
13 years, 7 months
Re: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
by Ed Burns
On Thu, Sep 30, 2010 at 11:22 PM, Edward Burns <edward.burns(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
13 years, 7 months
Re: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
by 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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
13 years, 7 months
Re: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
by Leonardo Uribe
> On 10/6/10 12:01 PM, Leonardo Uribe wrote:
>
>
>
> 2010/10/6 Blake Sullivan <blake.sullivan(a)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(a)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...".
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.
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.
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?
Leonardo Uribe
13 years, 7 months
