12:50 p.m.
>>>> On Mon, 11 Oct 2010 16:01:25 -0400, Andy Schwartz
<andy.schwartz(a)oracle.com> said:
AS> I had to take another look at the doc/code for the various context
AS> parameters in this area. My understanding is:
AS> - The "javax.faces.FACELETS_SUFFIX" context parameter specifies a single
AS> file extension that is mapped to the Facelets engine. This defaults to
AS> the ViewHandler.DEFAULT_FACELETS_SUFFIX value (ie. ".xhtml").
AS> - The "javax.faces.FACELETS_VIEW_MAPPINGS" context parameter allows
AS> multiple extensions/prefixes to be mapped to the Facelets engine. This
AS> context parameter has no default value.
AS> To be honest, it isn't clear to me why two context parameters were
AS> necessary, since it seems that FACES_VIEW_MAPPINGS is more general than
AS> FACELETS_SUFFIX, though I suppose we just inherited this from Facelets 1.x.
This is correct.
AS> With the default values as specified above, .view.xml extensions will
AS> not not routed to the Facelets engine. Instead, the application must
AS> explicitly specify this mapping via the FACELETS_VIEW_MAPPINGS context
AS> parameter. If we want to embrace this new file extension more fully, we
AS> either need to:
AS> - Enhance the DEFAULT_FACELETS_SUFFIX context parameter to allow it to
AS> support multiple values + change the default value to ".xhtml
AS> .view.xml". Or...
AS> - Specify a default value for the FACELETS_VIEW_MAPPINGS context parameter.
AS> Either of these seem acceptable to me.
I am reluctant to bind .view.xml to be "Facelets". Yes, right now
Mojarra is using the Facelets VDL impl to process .view.xml but I'd
rather leave the DEFAULT_FACELETS_SUFFIX and FACELET_VIEW_MAPPINGS
unchanged for 2.1. Note that I did change the value of
ViewHandler.DEFAULT_SUFFIX to be ".xhtml .view.xml .jsp".
I have just uploaded the latest expert community draft to
https://javaserverfaces-spec-public.dev.java.net/files/documents/1936/153...
The content relating to this issue is in Appendix A section 1.2.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
7:20 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Hi
These are the answers to the questions asked (answer inside the mail
sent could make things more confusing):
FIRST PROBLEM: Fix Resource Resolver
AS >> In what way (the ResourceResolver) does not work?
AS >> It this is broken, it definitely needs to be fixed.
AS >> We need more details on exactly what behavior is broken.
The problem happen only when suffix mapping is used. In few words,
When this mapping is used, it is required to check if a
physical resource exists, usually calling ExternalContext.getResource.
Since the algorithm described on the spec does not take into
account ResourceResolver, a http 404 not found response is sent back.
(The reference that needs to be fixed on the spec is JSF 2.0
section 7.5.2 Default ViewHandler Implementation, when it describe
the requeriments of ViewHandler.deriveViewId.)
AS >> What is the issue # for this problem?
AS >> Is this a Mojarra issue? MyFaces? Spec? All of the above?
The issue in MyFaces is this one:
https://issues.apache.org/jira/browse/MYFACES-2628
It was first mentioned on this mailing list under the topic:
[jsr-314-open] javax.faces.view.facelets.ResourceResolver cannot be
fully overriden
Then it was added some comments on this spec issue:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=781
It was also found this issue on Mojarra
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567
Maybe we should create an independent issue for this one on the spec
issue tracker
AS >> We are using it (ResourceResolver) here. Now I am getting worried
that
AS >> maybe our code is broken. :-) Though Jason also blogged on this
topic here:
AS >> http://blogs.steeplesoft.com/2010/05/putting-facelets-in-a-jar/
AS >> Which makes me think that this must be minimally working.
I think you are using ResourceResolver with applications that uses
prefix
mapping. The hack on the blog works but by accident. Try the same
example,
but without configure ResourceResolver and it will work, because we are
overriding ExternalContext.getResource, which it is used to check if a
resource
exists or not.
The proposal at first view, to solve this one is add a method on
ViewDeclarationLanguageFactory called existsViewId(), so the algorithm
on
ViewHandler.deriveViewId just delegate to this one and that one delegate
to
different ViewDeclarationLanguage implementations. But it seems better
to move all
logic from section 7.5.2 ViewHandler.deriveViewId. Here I have to
mention something
I said on this discussion:
[jsr-314-open] Should the ViewDeclarationLanguage be responsible to
indicate if a
viewId can be created?
On mojarra, this is the code on
MultiViewHandler.getViewDeclarationLanguage:
public ViewDeclarationLanguage
getViewDeclarationLanguage(FacesContext context,
String
viewId) {
String actualViewId = derivePhysicalViewId(context, viewId,
false);
return vdlFactory.getViewDeclarationLanguage(actualViewId);
}
Now on myfaces is this:
@Override
public ViewDeclarationLanguage getViewDeclarationLanguage(
FacesContext context, String viewId)
{
// return a suitable ViewDeclarationLanguage implementation for
the given viewId
return _vdlFactory.getViewDeclarationLanguage(viewId);
}
The difference is subtle, but very, very important. This method is
called from many
locations, but only once (from RestoreViewPhase) it is passed the
"raw" viewId.
To "derive" the physical viewId it is required to know if prefix or
suffix mapping is
used and if suffix mapping is used, try to check if a view
"resource" exists or not
with different derived ids with the extensions configured ".xhtml
.jsp".
In this case, MyFaces "derive" the physical viewId before call
getViewDeclarationLanguage
from RestoreViewPhase. In theory, we should call from RestoreViewPhase
algorithm a method
exposed by ViewHandler. I'm not have clear the details yet.
SECOND PROBLEM: Fix suffix definition for vdls
AS >> This seems like a good thing to do. Are you thinking that we'll
add a new
AS >> hook on ViewDeclarationLanguage that allows the VDL implementation
to decide
AS >> whether or not it can handle a particular view id?
In theory, both myfaces and mojarra has already that, but it is left as
an implementation
detail. Take a look at ViewDeclarationLanguageFactory implementation and
you'll see
some code to decide which VDL should handle the viewId identified (note
handle a viewId
is different to check if the viewId exists, which it is required for the
first one).
AS >> Do we have a spec issue logged for this topic?
Not yet. The intention is create one based on all previous discussion.
THIRD PROBLEM: Fix specific suffix handling for facelets vdl
BS>>>>>> In the JAR case, it doesn't care about the VDL at all,
it is
simply
BS>>>>>> loading the requested resources out of the JAR regardless
of
extension.
LU>>>>So, what's the point about have this configuration on a JAR, if
there will be no
LU>>>>resources using such extensions inside it?. If all resources used
by facelets are
LU>>>>inside the WAR or in the webapp directory, shouldn't that param
be
configured on
LU>>>>web.xml or only in faces config application resource
(WEB-INF/faces-config.xml).
LU>>>>It's more, if I have the xml configuration proposed on JAR
META-INF/faces-config.xml,
LU>>>>what someone could expect is the configuration applies to case 1
(composite
LU>>>>component resource files), and not globally, which it is the
intention.
AS>>I don't completely follow this. Could you explain?
The proposal "as is" has a problem. It we have the configuration on a
JAR, the way the
mappings are written does not suggest which resources applies to it, or
in other words,
it is not clear if the resources found outside the JAR are also affected
or not.
As I said before, a JAR file could contain resources that could be used
by facelets
in two situations:
1. On META-INF/resources/[localePrefix/][libraryName/]resourceName as a
composite
component resource file.
2. On any directory but it should be created a class that implements
javax.faces.view.facelets.ResourceResolver, so it can get the
resource properly.
If I put that configuration on a JAR, my first thought is this
configuration only applies to
the resources inside the JAR. Since ResourceResolver is affected by
"global mappings", this rule
should only applies to composite component definitions and related
facelets, right?.
But the intention is affect the "global mapping", since the resources
will be loaded through
ResourceResolver (I don't know your particular use case, so I'm
supposing here). It this
is true, it has sense to put it on a JAR, but that condition must be
made explicit, using
a more "suggestive" name and it should be possible to define a custom
ResourceResolver
from faces-config file, otherwise it will not be possible to wrap more
than 2 instances
(the default and the one from the web config param).
LU >>>> All three issues are related. All of them should be solved.
Delaying these issues
LU >>>> with partial hacks only makes things worst and even harder to
understand.
AS >> I agree that all three issues should be solved. FWIW, I think
that #3 can be
AS >> solved independently of #1 and #2. I don't quite see why these
issues should
AS >> be tightly coupled. I also don't think that the proposal to fix
#3 is a hack,
AS >> but if others think that it is, we of course need to resolve these
concerns.
From my point of view, this one is a particular case of the second one.
Why? because if you
add this 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>
You are not only saying "... process this suffix in mode ....", you also
are implicitly
mapping the suffix to facelets VDL. The mode is just a configuration
property that
the VDL must take into account to process a viewId with this suffix. Why
don't do
something like this (maybe you can find better names for the xml):
<faces-config-extension>
<vdl-configuration>
<vdl-id>facelets</vdl-id>
<vdl-class>xxx.yyy.zzz.MyCustomFaceletsVDLWrapper</vdl-class>
<vdl-global-resource-mapping>
<file-extension>.jspx</file-extension>
<vdl-resource-mapping-config> <!-- Saved on key/value map or
something like that -->
<process-as>jspx</process-as>
</vdl-resource-mapping-config>
</vdl-global-resource-mapping>
<vdl-global-resource-mapping>
<file-extension>.view.xml</file-extension>
<vdl-resource-mapping-config> <!-- Saved on key/value map or
something like that -->
<process-as>xml</process-as>
</vdl-resource-mapping-config>
</vdl-global-resource-mapping>
</vdl-configuration>
</faces-config-extension>
It is almost the same as we have before but with the following
differences:
1. Every VDL has an id (like with RenderKit)
2. There is an option to provide custom properties, that allow pass the
"mode".
3. <vdl-global-resource-mapping> tag says "... all resources that match
this mapping
in the webapp will be processed by this VDL using these configuration
params ..."
4. (Optional) Allow to provide a wrapper for a VDL implementation,
allowing to extend
it (maybe useful for gracelets????).
Did you see the relationship between all three problems?
- All of them require changes on
ViewDeclarationLanguage/ViewDeclarationLanguageFactory.
- Problem (1) is enough simple to solve, because it just require some code
relocation that already exists,
but it is necessary to update the spec.
- Problem (2) is the general case of (3), so we just need to change the
current patch a little bit.
- To make (3) and use it as expected we need (1) fixed.
I'm willing to contribute with this issue doing some code if necessary (I'll
try it to see how
far I can go).
Suggestions are welcome.
best regards,
Leonardo Uribe
12:02 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Hi
On this issue:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567
I attached a minimal patch to solve ResourceResolver problem. The idea is
just
method called:
public boolean existsViewId(FacesContext context, String viewId)
and add the method
ViewHandler.getViewDeclarationLanguageFromRawViewId(FacesContext, String)
to resolve the ambiguity on ViewHandler.getViewDeclarationLanguage.
regards,
Leonardo
2010/10/12 Leonardo Uribe <lu4242(a)gmail.com>
Hi
These are the answers to the questions asked (answer inside the mail
sent could make things more confusing):
FIRST PROBLEM: Fix Resource Resolver
AS >> In what way (the ResourceResolver) does not work?
AS >> It this is broken, it definitely needs to be fixed.
AS >> We need more details on exactly what behavior is broken.
The problem happen only when suffix mapping is used. In few words,
When this mapping is used, it is required to check if a
physical resource exists, usually calling ExternalContext.getResource.
Since the algorithm described on the spec does not take into
account ResourceResolver, a http 404 not found response is sent back.
(The reference that needs to be fixed on the spec is JSF 2.0
section 7.5.2 Default ViewHandler Implementation, when it describe
the requeriments of ViewHandler.deriveViewId.)
AS >> What is the issue # for this problem?
AS >> Is this a Mojarra issue? MyFaces? Spec? All of the above?
The issue in MyFaces is this one:
https://issues.apache.org/jira/browse/MYFACES-2628
It was first mentioned on this mailing list under the topic:
[jsr-314-open] javax.faces.view.facelets.ResourceResolver cannot be
fully overriden
Then it was added some comments on this spec issue:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=781
It was also found this issue on Mojarra
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567
Maybe we should create an independent issue for this one on the spec
issue tracker
AS >> We are using it (ResourceResolver) here. Now I am getting
worried that
AS >> maybe our code is broken. :-) Though Jason also blogged on this
topic here:
AS >> http://blogs.steeplesoft.com/2010/05/putting-facelets-in-a-jar/
AS >> Which makes me think that this must be minimally working.
I think you are using ResourceResolver with applications that uses
prefix
mapping. The hack on the blog works but by accident. Try the same
example,
but without configure ResourceResolver and it will work, because we are
overriding ExternalContext.getResource, which it is used to check if a
resource
exists or not.
The proposal at first view, to solve this one is add a method on
ViewDeclarationLanguageFactory called existsViewId(), so the algorithm
on
ViewHandler.deriveViewId just delegate to this one and that one
delegate to
different ViewDeclarationLanguage implementations. But it seems better
to move all
logic from section 7.5.2 ViewHandler.deriveViewId. Here I have to
mention something
I said on this discussion:
[jsr-314-open] Should the ViewDeclarationLanguage be responsible to
indicate if a
viewId can be created?
On mojarra, this is the code on
MultiViewHandler.getViewDeclarationLanguage:
public ViewDeclarationLanguage
getViewDeclarationLanguage(FacesContext context,
String
viewId) {
String actualViewId = derivePhysicalViewId(context, viewId,
false);
return vdlFactory.getViewDeclarationLanguage(actualViewId);
}
Now on myfaces is this:
@Override
public ViewDeclarationLanguage getViewDeclarationLanguage(
FacesContext context, String viewId)
{
// return a suitable ViewDeclarationLanguage implementation for
the given viewId
return _vdlFactory.getViewDeclarationLanguage(viewId);
}
The difference is subtle, but very, very important. This method is
called from many
locations, but only once (from RestoreViewPhase) it is passed the
"raw" viewId.
To "derive" the physical viewId it is required to know if prefix or
suffix mapping is
used and if suffix mapping is used, try to check if a view
"resource" exists or not
with different derived ids with the extensions configured ".xhtml
.jsp".
In this case, MyFaces "derive" the physical viewId before call
getViewDeclarationLanguage
from RestoreViewPhase. In theory, we should call from RestoreViewPhase
algorithm a method
exposed by ViewHandler. I'm not have clear the details yet.
SECOND PROBLEM: Fix suffix definition for vdls
AS >> This seems like a good thing to do. Are you thinking that we'll
add a new
AS >> hook on ViewDeclarationLanguage that allows the VDL
implementation to decide
AS >> whether or not it can handle a particular view id?
In theory, both myfaces and mojarra has already that, but it is left as
an implementation
detail. Take a look at ViewDeclarationLanguageFactory implementation
and you'll see
some code to decide which VDL should handle the viewId identified (note
handle a viewId
is different to check if the viewId exists, which it is required for
the first one).
AS >> Do we have a spec issue logged for this topic?
Not yet. The intention is create one based on all previous discussion.
THIRD PROBLEM: Fix specific suffix handling for facelets vdl
BS>>>>>> In the JAR case, it doesn't care about the VDL at all,
it is
simply
BS>>>>>> loading the requested resources out of the JAR regardless
of
extension.
LU>>>>So, what's the point about have this configuration on a JAR,
if
there will be no
LU>>>>resources using such extensions inside it?. If all resources used
by facelets are
LU>>>>inside the WAR or in the webapp directory, shouldn't that
param
be configured on
LU>>>>web.xml or only in faces config application resource
(WEB-INF/faces-config.xml).
LU>>>>It's more, if I have the xml configuration proposed on JAR
META-INF/faces-config.xml,
LU>>>>what someone could expect is the configuration applies to case 1
(composite
LU>>>>component resource files), and not globally, which it is the
intention.
AS>>I don't completely follow this. Could you explain?
The proposal "as is" has a problem. It we have the configuration on a
JAR, the way the
mappings are written does not suggest which resources applies to it, or
in other words,
it is not clear if the resources found outside the JAR are also
affected or not.
As I said before, a JAR file could contain resources that could be used
by facelets
in two situations:
1. On META-INF/resources/[localePrefix/][libraryName/]resourceName as a
composite
component resource file.
2. On any directory but it should be created a class that implements
javax.faces.view.facelets.ResourceResolver, so it can get the
resource properly.
If I put that configuration on a JAR, my first thought is this
configuration only applies to
the resources inside the JAR. Since ResourceResolver is affected by
"global mappings", this rule
should only applies to composite component definitions and related
facelets, right?.
But the intention is affect the "global mapping", since the resources
will be loaded through
ResourceResolver (I don't know your particular use case, so I'm
supposing here). It this
is true, it has sense to put it on a JAR, but that condition must be
made explicit, using
a more "suggestive" name and it should be possible to define a custom
ResourceResolver
from faces-config file, otherwise it will not be possible to wrap more
than 2 instances
(the default and the one from the web config param).
LU >>>> All three issues are related. All of them should be solved.
Delaying these issues
LU >>>> with partial hacks only makes things worst and even harder to
understand.
AS >> I agree that all three issues should be solved. FWIW, I think
that #3 can be
AS >> solved independently of #1 and #2. I don't quite see why these
issues should
AS >> be tightly coupled. I also don't think that the proposal to fix
#3 is a hack,
AS >> but if others think that it is, we of course need to resolve
these concerns.
From my point of view, this one is a particular case of the second one.
Why? because if you
add this 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>
You are not only saying "... process this suffix in mode ....", you
also are implicitly
mapping the suffix to facelets VDL. The mode is just a configuration
property that
the VDL must take into account to process a viewId with this suffix.
Why don't do
something like this (maybe you can find better names for the xml):
<faces-config-extension>
<vdl-configuration>
<vdl-id>facelets</vdl-id>
<vdl-class>xxx.yyy.zzz.MyCustomFaceletsVDLWrapper</vdl-class>
<vdl-global-resource-mapping>
<file-extension>.jspx</file-extension>
<vdl-resource-mapping-config> <!-- Saved on key/value map or
something like that -->
<process-as>jspx</process-as>
</vdl-resource-mapping-config>
</vdl-global-resource-mapping>
<vdl-global-resource-mapping>
<file-extension>.view.xml</file-extension>
<vdl-resource-mapping-config> <!-- Saved on key/value map or
something like that -->
<process-as>xml</process-as>
</vdl-resource-mapping-config>
</vdl-global-resource-mapping>
</vdl-configuration>
</faces-config-extension>
It is almost the same as we have before but with the following
differences:
1. Every VDL has an id (like with RenderKit)
2. There is an option to provide custom properties, that allow pass the
"mode".
3. <vdl-global-resource-mapping> tag says "... all resources that match
this mapping
in the webapp will be processed by this VDL using these
configuration params ..."
4. (Optional) Allow to provide a wrapper for a VDL implementation,
allowing to extend
it (maybe useful for gracelets????).
Did you see the relationship between all three problems?
- All of them require changes on
ViewDeclarationLanguage/ViewDeclarationLanguageFactory.
- Problem (1) is enough simple to solve, because it just require some code
relocation that already exists,
but it is necessary to update the spec.
- Problem (2) is the general case of (3), so we just need to change the
current patch a little bit.
- To make (3) and use it as expected we need (1) fixed.
I'm willing to contribute with this issue doing some code if necessary
(I'll try it to see how
far I can go).
Suggestions are welcome.
best regards,
Leonardo Uribe
4:18 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Hi
For the problem related to ResourceResolver I created this issue:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=893
And attached two patches:
- Minimal proposal to fix ResourceResolver problem
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
- Solution enhanced that delegate extension configuration to VDL
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
From the point of view of the spec the proposal is add this methods:
javax.faces.application.ViewHandler (and ViewHandlerWrapper)
// Resolve the ambiguity found on getViewDeclarationLanguage() method.
Only called from Restore View Phase.
public ViewDeclarationLanguage
getViewDeclarationLanguageFromRawViewId(FacesContext context, String viewId)
javax.faces.view.ViewDeclarationLanguageFactory
/**
* <p class="changed_added_2_1">Indicate if the viewId identified can
be
* located by any VDL returned by this factory</p>
*/
public boolean existsViewId(FacesContext context, String viewId)
/**
* <p class="changed_added_2_1">Return an Array with the configured
file
* extensions that can be processed by any VDL returned by this
factory</p>
*/
public String[] getConfiguredExtensions()
javax.faces.view.ViewDeclarationLanguage
/**
* <p class="changed_added_2_1">Indicate if the viewId identified can
be
* located by any VDL returned by this factory</p>
*/
public boolean existsViewId(FacesContext context, String viewId)
/**
* <p class="changed_added_2_1">Return an Array with the configured
file
* extensions that can be processed by any VDL returned by this
factory</p>
*/
public String[] getConfiguredExtensions()
Looking the patch, you'll see more clear my intention. If solving these
problems:
1. Fix ResourceResolver.
1.1 Fix getViewDeclarationLanguage() ambiguity.
1.2 Fix section 7.5.2 to delegate the responsibility of file extension
calculation to VDL,
to allow other VDL work correctly.
2. Fix suffix definition for vdls
3. Fix specific suffix handling for facelets vdl
It is resolved (1), easily it will point to 2. If we add the solution
proposed for (1) with
the solution proposed for (3), things are getting better, but if it is done
an extra minimal
effort on (2) based on the previous patches, the result will be even better.
best regards,
Leonardo Uribe
2010/10/13 Leonardo Uribe <lu4242(a)gmail.com>
Hi
On this issue:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567
I attached a minimal patch to solve ResourceResolver problem. The idea is
just
method called:
public boolean existsViewId(FacesContext context, String viewId)
and add the method
ViewHandler.getViewDeclarationLanguageFromRawViewId(FacesContext, String)
to resolve the ambiguity on ViewHandler.getViewDeclarationLanguage.
regards,
Leonardo
2010/10/12 Leonardo Uribe <lu4242(a)gmail.com>
Hi
>
> These are the answers to the questions asked (answer inside the mail
> sent could make things more confusing):
>
> FIRST PROBLEM: Fix Resource Resolver
>
> AS >> In what way (the ResourceResolver) does not work?
> AS >> It this is broken, it definitely needs to be fixed.
> AS >> We need more details on exactly what behavior is broken.
>
> The problem happen only when suffix mapping is used. In few words,
> When this mapping is used, it is required to check if a
> physical resource exists, usually calling ExternalContext.getResource.
>
> Since the algorithm described on the spec does not take into
> account ResourceResolver, a http 404 not found response is sent back.
> (The reference that needs to be fixed on the spec is JSF 2.0
> section 7.5.2 Default ViewHandler Implementation, when it describe
> the requeriments of ViewHandler.deriveViewId.)
>
> AS >> What is the issue # for this problem?
> AS >> Is this a Mojarra issue? MyFaces? Spec? All of the above?
>
> The issue in MyFaces is this one:
>
> https://issues.apache.org/jira/browse/MYFACES-2628
>
> It was first mentioned on this mailing list under the topic:
>
> [jsr-314-open] javax.faces.view.facelets.ResourceResolver cannot be
> fully overriden
>
> Then it was added some comments on this spec issue:
>
>
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=781
>
> It was also found this issue on Mojarra
>
> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567
>
> Maybe we should create an independent issue for this one on the spec
> issue tracker
>
> AS >> We are using it (ResourceResolver) here. Now I am getting
> worried that
> AS >> maybe our code is broken. :-) Though Jason also blogged on this
> topic here:
> AS >> http://blogs.steeplesoft.com/2010/05/putting-facelets-in-a-jar/
> AS >> Which makes me think that this must be minimally working.
>
> I think you are using ResourceResolver with applications that uses
> prefix
> mapping. The hack on the blog works but by accident. Try the same
> example,
> but without configure ResourceResolver and it will work, because we
> are
> overriding ExternalContext.getResource, which it is used to check if a
> resource
> exists or not.
>
> The proposal at first view, to solve this one is add a method on
> ViewDeclarationLanguageFactory called existsViewId(), so the algorithm
> on
> ViewHandler.deriveViewId just delegate to this one and that one
> delegate to
> different ViewDeclarationLanguage implementations. But it seems better
> to move all
> logic from section 7.5.2 ViewHandler.deriveViewId. Here I have to
> mention something
> I said on this discussion:
>
>
> [jsr-314-open] Should the ViewDeclarationLanguage be responsible to
> indicate if a
> viewId can be created?
>
> On mojarra, this is the code on
> MultiViewHandler.getViewDeclarationLanguage:
>
> public ViewDeclarationLanguage
> getViewDeclarationLanguage(FacesContext context,
> String
> viewId) {
>
> String actualViewId = derivePhysicalViewId(context, viewId,
> false);
> return vdlFactory.getViewDeclarationLanguage(actualViewId);
>
> }
>
> Now on myfaces is this:
>
> @Override
> public ViewDeclarationLanguage getViewDeclarationLanguage(
> FacesContext context, String viewId)
> {
> // return a suitable ViewDeclarationLanguage implementation
> for the given viewId
> return _vdlFactory.getViewDeclarationLanguage(viewId);
> }
>
> The difference is subtle, but very, very important. This method is
> called from many
> locations, but only once (from RestoreViewPhase) it is passed the
> "raw" viewId.
> To "derive" the physical viewId it is required to know if prefix
> or suffix mapping is
> used and if suffix mapping is used, try to check if a view
> "resource" exists or not
> with different derived ids with the extensions configured ".xhtml
> .jsp".
>
> In this case, MyFaces "derive" the physical viewId before call
> getViewDeclarationLanguage
> from RestoreViewPhase. In theory, we should call from RestoreViewPhase
> algorithm a method
> exposed by ViewHandler. I'm not have clear the details yet.
>
> SECOND PROBLEM: Fix suffix definition for vdls
>
> AS >> This seems like a good thing to do. Are you thinking that we'll
> add a new
> AS >> hook on ViewDeclarationLanguage that allows the VDL
> implementation to decide
> AS >> whether or not it can handle a particular view id?
>
> In theory, both myfaces and mojarra has already that, but it is left
> as an implementation
> detail. Take a look at ViewDeclarationLanguageFactory implementation
> and you'll see
> some code to decide which VDL should handle the viewId identified
> (note handle a viewId
> is different to check if the viewId exists, which it is required for
> the first one).
>
> AS >> Do we have a spec issue logged for this topic?
>
> Not yet. The intention is create one based on all previous discussion.
>
>
> THIRD PROBLEM: Fix specific suffix handling for facelets vdl
>
>
> BS>>>>>> In the JAR case, it doesn't care about the VDL at
all, it is
> simply
> BS>>>>>> loading the requested resources out of the JAR
regardless of
> extension.
>
> LU>>>>So, what's the point about have this configuration on a
JAR, if
> there will be no
> LU>>>>resources using such extensions inside it?. If all resources
> used by facelets are
> LU>>>>inside the WAR or in the webapp directory, shouldn't that
param
> be configured on
> LU>>>>web.xml or only in faces config application resource
> (WEB-INF/faces-config.xml).
>
> LU>>>>It's more, if I have the xml configuration proposed on JAR
> META-INF/faces-config.xml,
> LU>>>>what someone could expect is the configuration applies to case
1
> (composite
> LU>>>>component resource files), and not globally, which it is the
> intention.
>
> AS>>I don't completely follow this. Could you explain?
>
> The proposal "as is" has a problem. It we have the configuration on a
> JAR, the way the
> mappings are written does not suggest which resources applies to it,
> or in other words,
> it is not clear if the resources found outside the JAR are also
> affected or not.
>
> As I said before, a JAR file could contain resources that could be
> used by facelets
> in two situations:
>
> 1. On META-INF/resources/[localePrefix/][libraryName/]resourceName as
> a composite
> component resource file.
>
> 2. On any directory but it should be created a class that implements
> javax.faces.view.facelets.ResourceResolver, so it can get the
> resource properly.
>
> If I put that configuration on a JAR, my first thought is this
> configuration only applies to
> the resources inside the JAR. Since ResourceResolver is affected by
> "global mappings", this rule
> should only applies to composite component definitions and related
> facelets, right?.
>
> But the intention is affect the "global mapping", since the resources
> will be loaded through
> ResourceResolver (I don't know your particular use case, so I'm
> supposing here). It this
> is true, it has sense to put it on a JAR, but that condition must be
> made explicit, using
> a more "suggestive" name and it should be possible to define a custom
> ResourceResolver
> from faces-config file, otherwise it will not be possible to wrap more
> than 2 instances
> (the default and the one from the web config param).
>
> LU >>>> All three issues are related. All of them should be solved.
> Delaying these issues
> LU >>>> with partial hacks only makes things worst and even harder
to
> understand.
>
> AS >> I agree that all three issues should be solved. FWIW, I think
> that #3 can be
> AS >> solved independently of #1 and #2. I don't quite see why these
> issues should
> AS >> be tightly coupled. I also don't think that the proposal to fix
> #3 is a hack,
> AS >> but if others think that it is, we of course need to resolve
> these concerns.
>
> From my point of view, this one is a particular case of the second
> one. Why? because if you
> add this 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>
>
> You are not only saying "... process this suffix in mode ....", you
> also are implicitly
> mapping the suffix to facelets VDL. The mode is just a configuration
> property that
> the VDL must take into account to process a viewId with this suffix.
> Why don't do
> something like this (maybe you can find better names for the xml):
>
> <faces-config-extension>
> <vdl-configuration>
> <vdl-id>facelets</vdl-id>
> <vdl-class>xxx.yyy.zzz.MyCustomFaceletsVDLWrapper</vdl-class>
> <vdl-global-resource-mapping>
>
> <file-extension>.jspx</file-extension>
> <vdl-resource-mapping-config> <!-- Saved on key/value map or
> something like that -->
>
> <process-as>jspx</process-as>
> </vdl-resource-mapping-config>
> </vdl-global-resource-mapping>
> <vdl-global-resource-mapping>
>
> <file-extension>.view.xml</file-extension>
> <vdl-resource-mapping-config> <!-- Saved on key/value map or
> something like that -->
>
> <process-as>xml</process-as>
> </vdl-resource-mapping-config>
> </vdl-global-resource-mapping>
> </vdl-configuration>
> </faces-config-extension>
>
> It is almost the same as we have before but with the following
> differences:
>
> 1. Every VDL has an id (like with RenderKit)
> 2. There is an option to provide custom properties, that allow pass
> the "mode".
> 3. <vdl-global-resource-mapping> tag says "... all resources that
> match this mapping
> in the webapp will be processed by this VDL using these
> configuration params ..."
> 4. (Optional) Allow to provide a wrapper for a VDL implementation,
> allowing to extend
> it (maybe useful for gracelets????).
>
> Did you see the relationship between all three problems?
>
> - All of them require changes on
> ViewDeclarationLanguage/ViewDeclarationLanguageFactory.
> - Problem (1) is enough simple to solve, because it just require some code
> relocation that already exists,
> but it is necessary to update the spec.
> - Problem (2) is the general case of (3), so we just need to change the
> current patch a little bit.
> - To make (3) and use it as expected we need (1) fixed.
>
> I'm willing to contribute with this issue doing some code if necessary
> (I'll try it to see how
> far I can go).
>
>
> Suggestions are welcome.
>
> best regards,
>
> Leonardo Uribe
>
4:47 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Hey Leonardo -
I haven't had a chance to review your patches just yet, but one quick
question about this:
javax.faces.application.ViewHandler (and ViewHandlerWrapper)
// Resolve the ambiguity found on getViewDeclarationLanguage()
method. Only called from Restore View Phase.
public ViewDeclarationLanguage
getViewDeclarationLanguageFromRawViewId(FacesContext context, String
viewId)
Why not use ViewHandler.deriveViewId() and specify that
ViewHandler.getViewDeclarationLanguage() takes a derived view id?
Andy
5:14 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Hi Andy
2010/10/13 Andy Schwartz <andy.schwartz(a)oracle.com>
Hey Leonardo -
I haven't had a chance to review your patches just yet, but one quick
question about this:
javax.faces.application.ViewHandler (and ViewHandlerWrapper)
>
> // Resolve the ambiguity found on getViewDeclarationLanguage() method.
> Only called from Restore View Phase.
> public ViewDeclarationLanguage
> getViewDeclarationLanguageFromRawViewId(FacesContext context, String viewId)
>
Why not use ViewHandler.deriveViewId() and specify that
ViewHandler.getViewDeclarationLanguage() takes a derived view id?
I tried to use it in MyFaces long time ago but unfortunately use it breaks
TCK test, because deriveViewId() check at the end if the physical resource
exists and if it does not, return null.
Leonardo
Andy
12:58 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Hey Leonardo -
Backing up in the thread a bit...
On 10/13/10 5:18 PM, Leonardo Uribe wrote:
Hi
For the problem related to ResourceResolver I created this issue:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=893
And attached two patches:
- Minimal proposal to fix ResourceResolver problem
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
- Solution enhanced that delegate extension configuration to VDL
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
From the point of view of the spec the proposal is add this methods:
<snip>
Looking the patch, you'll see more clear my intention. If solving
these problems:
1. Fix ResourceResolver.
1.1 Fix getViewDeclarationLanguage() ambiguity.
1.2 Fix section 7.5.2 to delegate the responsibility of file extension
calculation to VDL,
to allow other VDL work correctly.
Okay, I finally get it. :-)
The problem with the behavior specified in 7.5.2 is that it provides
special-case treatment for Facelets. Other VDLs that define their own
extension mappings are simply out of luck. Non-Facelets VDL mappings
won't be considered when deriving view ids.
ViewHandler should be VDL-agnostic and should delegate to
ViewDeclarationLanguageFactory/ViewDeclarationLanguage for any
VDL-specific functionality. Requiring the ViewHandler implementation to
have intimate knowledge of Facelets violates the desired separation of
responsibilities.
We should fix this.
Seems like the we could either:
- Have the ViewDeclarationLangaugeFactory/ViewDeclarationLanguage cough
up extensions for which they are configured. (Your recommendation).
- Delegate deriveViewId() to
ViewDeclarationLanguageFactory/ViewDeclarationLanguage.
Either of these approaches would work for me.
FWIW, this seems like a separate issue from the ResourceResolver issue -
ie. these problems can be solved independently.
2. Fix suffix definition for vdls
Er... now I am getting confused. We've been dealing with various issues
relating to suffix handling. Can you remind me which one this
corresponds to? Is this providing a generic mechanism for registering
VDLs by suffix instead of requiring each VDL to define its own context
parameters?
Earlier you proposed exposing this sort of configuration in
faces-config.xml, eg:
<faces-config-extension>
<vdl-configuration>
<vdl-id>facelets</vdl-id>
<vdl-class>xxx.yyy.zzz.MyCustomFaceletsVDLWrapper</vdl-class>
<vdl-global-resource-mapping>
<file-extension>.jspx</file-extension>
<vdl-resource-mapping-config> <!-- Saved on key/value map
or something like that -->
<process-as>jspx</process-as>
</vdl-resource-mapping-config>
</vdl-global-resource-mapping>
<vdl-global-resource-mapping>
<file-extension>.view.xml</file-extension>
<vdl-resource-mapping-config> <!-- Saved on key/value map
or something like that -->
<process-as>xml</process-as>
</vdl-resource-mapping-config>
</vdl-global-resource-mapping>
</vdl-configuration>
</faces-config-extension>
Presumably this would provide a generic way to:
- Register new VDLs (instead of requiring context params like
FACELETS_VIEW_MAPPINGS_PARAM_NAME)
- Wrap existing VDLs
- Map VDLs to specific file extensions (or possible prefixes?)
- Specify VDL-specific parameters
I like this idea as it would definitely make life easier for VDL authors
and for frameworks that need to wrap VDLs. However, we may want to
break this up somewhat - eg. separate the configuration for registering
a VDL from the configuration for mapping the VDL to a specific
prefix/suffix, similar to how web.xml separates the <servlet> and
<servlet-mapping> configuration.
Regarding:
<vdl-resource-mapping-config> <!-- Saved on
key/value map
or something like that -->
<process-as>jspx</process-as>
</vdl-resource-mapping-config>
Were you thinking that the VDL implementations would participate in the
parsing/processing of this content? Without this, it seems like it
would be difficult to have VDL-specific elements such as <process-as> -
ie. we might need to resort to generic parameter (name/value) elements,
similar to web.xml.
3. Fix specific suffix handling for facelets vdl
It is resolved (1), easily it will point to 2. If we add the solution
proposed for (1) with
the solution proposed for (3), things are getting better, but if it is
done an extra minimal
effort on (2) based on the previous patches, the result will be even
better.
I am still a bit lost on the #s and the dependencies between these
items. I think that we should focus on identifying which changes we
minimally need to get into 2.1 in order to address the most fundamental
issues without hindering our ability to build up fuller solutions in 2.2.
Andy
3:43 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Hi
2010/10/18 Andy Schwartz <andy.schwartz(a)oracle.com>
Hey Leonardo -
Backing up in the thread a bit...
On 10/13/10 5:18 PM, Leonardo Uribe wrote:
> Hi
>
> For the problem related to ResourceResolver I created this issue:
>
>
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=893
>
> And attached two patches:
>
> - Minimal proposal to fix ResourceResolver problem
>
>
>
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
>
> - Solution enhanced that delegate extension configuration to VDL
>
>
>
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
>
> From the point of view of the spec the proposal is add this methods:
>
>
<snip>
>
> Looking the patch, you'll see more clear my intention. If solving these
> problems:
>
> 1. Fix ResourceResolver.
> 1.1 Fix getViewDeclarationLanguage() ambiguity.
> 1.2 Fix section 7.5.2 to delegate the responsibility of file extension
> calculation to VDL,
> to allow other VDL work correctly.
>
Okay, I finally get it. :-)
The problem with the behavior specified in 7.5.2 is that it provides
special-case treatment for Facelets. Other VDLs that define their own
extension mappings are simply out of luck. Non-Facelets VDL mappings won't
be considered when deriving view ids.
That's right.
ViewHandler should be VDL-agnostic and should delegate to
ViewDeclarationLanguageFactory/ViewDeclarationLanguage for any VDL-specific
functionality. Requiring the ViewHandler implementation to have intimate
knowledge of Facelets violates the desired separation of responsibilities.
We should fix this.
Yes.
Seems like the we could either:
- Have the ViewDeclarationLangaugeFactory/ViewDeclarationLanguage cough up
extensions for which they are configured. (Your recommendation).
- Delegate deriveViewId() to
ViewDeclarationLanguageFactory/ViewDeclarationLanguage.
Either of these approaches would work for me.
FWIW, this seems like a separate issue from the ResourceResolver issue -
ie. these problems can be solved independently.
It seems, but note the algorithm required to deriveViewId() should call
ResourceResolver to check for resources, specially when suffix mapping is
used, so if it is necessary to change section 7.5.2 for each problem, it
could be good to do both changes at once.
> 2. Fix suffix definition for vdls
>
Er... now I am getting confused. We've been dealing with various issues
relating to suffix handling. Can you remind me which one this corresponds
to? Is this providing a generic mechanism for registering VDLs by suffix
instead of requiring each VDL to define its own context parameters?
Right now, we use web-config params to configure which resources will be
processed by each VDL. Yes, the idea is provide a generic mechanism for
registering VDLs by suffix. Additionally, that mechanism could provide
special config params to handle each suffix when required.
Earlier you proposed exposing this sort of configuration in
faces-config.xml, eg:
<faces-config-extension>
> <vdl-configuration>
> <vdl-id>facelets</vdl-id>
> <vdl-class>xxx.yyy.zzz.MyCustomFaceletsVDLWrapper</vdl-class>
> <vdl-global-resource-mapping>
>
> <file-extension>.jspx</file-extension>
> <vdl-resource-mapping-config> <!-- Saved on key/value map or
> something like that -->
>
> <process-as>jspx</process-as>
> </vdl-resource-mapping-config>
> </vdl-global-resource-mapping>
> <vdl-global-resource-mapping>
>
> <file-extension>.view.xml</file-extension>
> <vdl-resource-mapping-config> <!-- Saved on key/value map or
> something like that -->
>
> <process-as>xml</process-as>
> </vdl-resource-mapping-config>
> </vdl-global-resource-mapping>
> </vdl-configuration>
> </faces-config-extension>
>
Presumably this would provide a generic way to:
- Register new VDLs (instead of requiring context params like
FACELETS_VIEW_MAPPINGS_PARAM_NAME)
- Wrap existing VDLs
- Map VDLs to specific file extensions (or possible prefixes?)
- Specify VDL-specific parameters
I like this idea as it would definitely make life easier for VDL authors
and for frameworks that need to wrap VDLs. However, we may want to break
this up somewhat - eg. separate the configuration for registering a VDL from
the configuration for mapping the VDL to a specific prefix/suffix, similar
to how web.xml separates the <servlet> and <servlet-mapping> configuration.
Sounds good. Maybe in this case we could have VDL registering inside
<faces-config> tag like renderkit does:
<view-declaration-language>
<view-declaration-language-id>javax.faces.Jsp</view-declaration-language-id>
<view-declaration-language-class>my.bizarre.vdl.WrapperForJspOnly</view-declaration-language-class>
</view-declaration-language>
and VDL prefix/suffix mapping inside <faces-config-extension> tag.
Regarding:
<vdl-resource-mapping-config> <!-- Saved on key/value map or
> something like that -->
>
> <process-as>jspx</process-as>
> </vdl-resource-mapping-config>
>
Were you thinking that the VDL implementations would participate in the
parsing/processing of this content? Without this, it seems like it would be
difficult to have VDL-specific elements such as <process-as> - ie. we might
need to resort to generic parameter (name/value) elements, similar to
web.xml.
I was thinking on add a method on VDL called (maybe you can find a better
name)
public void addResourceMapping(String fileExtension, Map<String,String>
configurationMap)
to call it when faces-config.xml were parsed and pass that information. Yes,
maybe a syntax similar to web.xml could do the job better in this case:
<config-param>
<description>Some description</description>
<param-name>process-as</param-name>
<param-value>jspx</param-value>
</config-param>
> 3. Fix specific suffix handling for facelets vdl
>
> It is resolved (1), easily it will point to 2. If we add the solution
> proposed for (1) with
> the solution proposed for (3), things are getting better, but if it is
> done an extra minimal
> effort on (2) based on the previous patches, the result will be even
> better.
>
I am still a bit lost on the #s and the dependencies between these items.
I think that we should focus on identifying which changes we minimally need
to get into 2.1 in order to address the most fundamental issues without
hindering our ability to build up fuller solutions in 2.2.
I think the list you did on a previous mail is very clear:
I would very much like to see much of this addressed for 2.1 as
well.
We've covered quite a bit of ground here. Let's recap what we are looking
for.
These seem to be the minimal requirements:
1. The ViewHandler.getViewDeclarationLanguage() should be clear that it
expects "derived" view ids.
2. We need some way to safely derive view ids from the restore view phase.
This means that we either need to be able to use the existing
ViewHandler.deriveViewId() without triggering TCK failures, or we need a new
method on ViewHandler that performs the same functionality as deriveViewId()
without requiring that the derived view id passes the existence check.
3. We need a method on ViewDeclarationLanguage for testing view existence,
eg. viewExists(). We should use this instead of directly calling
ExternalContext.getResource() when checking to see whether a viewId
corresponds to a physical view.
4. We need some way to wrap a specific VDL (eg. the JSP VDL). The minimal
solution would be to introduce a VDL id (eg.
ViewDeclarationLanguage.getId()) and define standard ids for the JSP and
Facelets VDLs.
In addition, these requirements would be good to address:
5. Generalize the ResourceResolver API so that it can be shared across
VDLs. This would involve: creating a new version of this contract that
lives outside of javax.faces.view.facelets, allowing resource resolvers to
be declared in faces-config.xml, exposing an Application-level API for
retrieving the ResourceResolver.
6. Allow #4 to be accomplished declaratively via faces-config.xml.
Did I miss anything? Or, I should say, did I miss anything from this
branch of the discussion? I still need to go back and review some of the
topics that I ignored from the original discussion. :-)
For me, #1-#4 are the key requirements that I would like to address in
2.1. #5 and #6 would be improvements that I would also welcome, but for my
own needs I can get by if we have to defer these until 2.2.
Yes, I agree with you that #1-#4 are the minimal points that need to be
address in 2.1. But I think personally that do #6 is better that include the
patch proposed intially (facelets-processing), because after all, the code
to make #6 work is not quite different, but if that's not possible the
initial patch is ok. Anyway, I'll be happy if #1-#4 could be solved for 2.1.
regards,
Leonardo Uribe
5:32 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
On 10/18/10 4:43 PM, Leonardo Uribe wrote:
Hi
2010/10/18 Andy Schwartz <andy.schwartz(a)oracle.com
<mailto:andy.schwartz@oracle.com>>
These seem to be the minimal requirements:
1. The ViewHandler.getViewDeclarationLanguage() should be clear
that it expects "derived" view ids.
2. We need some way to safely derive view ids from the restore
view phase. This means that we either need to be able to use the
existing ViewHandler.deriveViewId() without triggering TCK
failures, or we need a new method on ViewHandler that performs the
same functionality as deriveViewId() without requiring that the
derived view id passes the existence check.
3. We need a method on ViewDeclarationLanguage for testing view
existence, eg. viewExists(). We should use this instead of
directly calling ExternalContext.getResource() when checking to
see whether a viewId corresponds to a physical view.
4. We need some way to wrap a specific VDL (eg. the JSP VDL). The
minimal solution would be to introduce a VDL id (eg.
ViewDeclarationLanguage.getId()) and define standard ids for the
JSP and Facelets VDLs.
Yes, I agree with you that #1-#4 are the minimal points that need to
be address in 2.1. But I think personally that do #6 is better that
include the patch proposed intially (facelets-processing), because
after all, the code to make #6 work is not quite different, but if
that's not possible the initial patch is ok. Anyway, I'll be happy if
#1-#4 could be solved for 2.1.
Great, thanks Leonardo.
I have attached a patch to issue 893 that implements these changes. See:
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
Note that this is very similar to the approach that you took in your
patch, but with some of the changes that we have discussed in this thread.
We'll need to review the following new APIs:
1. ViewHandler.deriveLogicalViewId()
We've got two options here:
- Add an overload of deriveViewId() that takes a boolean to indicate
whether or not to test for a physical resource. Or...
- Pick a new method name.
I went for the latter approach:
/**
* <p class="changed_added_2_1">Derive and return the viewId from
* the current request, or the argument input by following the
* algorithm defined in specification section JSF.7.5.2. Note that
* unlike <code>deriveViewId()</code>, this method does not
require that
* a physical view be present.</p>
*
* <p>The default implementation of this method simply returns
* rawViewId unchanged.</p>
*
* @param context the <code>FacesContext</code> for this request
*
* @param rawViewId the <code>viewId</code> to derive,
*
* @since 2.1
*/
public String deriveLogicalViewId(FacesContext context, String
rawViewId) {
We can revisit this decision if folks do not like this.
2. ViewDeclarationLanguage.viewExists()
/**
* <p class="changed_added_2_1">Tests whether a physical resource
* corresponding to the specified viewId exists.</p>
*
* <p>The default implementation uses
* <code>ExternalContext.getResource()</code> to locate the physical
* resource.</p>
*
* @param context The <code>FacesContext</code> for this request.
* @param viewId the view id to test
*
* @since 2.1
*/
public boolean viewExists(FacesContext context,
String viewId) {
Note that I did not add any new methods to
ViewDeclarationLanguageFactory. Code that needs to check for existence
can simply grab the VDL and perform the test.
3. ViewDeclarationLanguage.getId()
/**
* <p class="changed_added_2_1">Returns a non-null String that can
be
* used to identify this view declaration language.</p>
*
* <p>The default implementation returns the empty string. Subclasses
* should override to return an id that uniquely identifies the
* view declaration language implementation.</p>
*
* @since 2.1
*/
public String getId() {
Nothing too exciting here. I suppose this could have been abstract, but
figured a default implementation that returns the empty string would be
acceptable.
4. ViewDeclarationLanguage id constants
/**
* <p class="changed_added_2_0">Identifier for the JSP view
declaration
* language.</p>
*
* @since 2.1
*/
public final static String JSP_VIEW_DECLARATION_LANGUAGE_ID =
"java.faces.JSP";
/**
* <p class="changed_added_2_0">Identifier for the Facelets view
* declaration language.</p>
*
* @since 2.1
*/
public final static String FACELETS_VIEW_DECLARATION_LANGUAGE_ID =
"java.faces.Facelets";
Thoughts?
Andy
9:01 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
For ViewDeclarationLanguage.getId(), why don't we use the fully
qualified classname as the default implementation?
-- Blake Sullivan
On 10/20/10 3:32 PM, Andy Schwartz wrote:
On 10/18/10 4:43 PM, Leonardo Uribe wrote:
> Hi
>
> 2010/10/18 Andy Schwartz <andy.schwartz(a)oracle.com
> <mailto:andy.schwartz@oracle.com>>
>
>
>
> These seem to be the minimal requirements:
>
> 1. The ViewHandler.getViewDeclarationLanguage() should be clear
> that it expects "derived" view ids.
> 2. We need some way to safely derive view ids from the restore
> view phase. This means that we either need to be able to use the
> existing ViewHandler.deriveViewId() without triggering TCK
> failures, or we need a new method on ViewHandler that performs the
> same functionality as deriveViewId() without requiring that the
> derived view id passes the existence check.
> 3. We need a method on ViewDeclarationLanguage for testing view
> existence, eg. viewExists(). We should use this instead of
> directly calling ExternalContext.getResource() when checking to
> see whether a viewId corresponds to a physical view.
> 4. We need some way to wrap a specific VDL (eg. the JSP VDL). The
> minimal solution would be to introduce a VDL id (eg.
> ViewDeclarationLanguage.getId()) and define standard ids for the
> JSP and Facelets VDLs.
>
>
> Yes, I agree with you that #1-#4 are the minimal points that need to
> be address in 2.1. But I think personally that do #6 is better that
> include the patch proposed intially (facelets-processing), because
> after all, the code to make #6 work is not quite different, but if
> that's not possible the initial patch is ok. Anyway, I'll be happy if
> #1-#4 could be solved for 2.1.
Great, thanks Leonardo.
I have attached a patch to issue 893 that implements these changes. See:
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
Note that this is very similar to the approach that you took in your
patch, but with some of the changes that we have discussed in this
thread.
We'll need to review the following new APIs:
1. ViewHandler.deriveLogicalViewId()
We've got two options here:
- Add an overload of deriveViewId() that takes a boolean to indicate
whether or not to test for a physical resource. Or...
- Pick a new method name.
I went for the latter approach:
> /**
> * <p class="changed_added_2_1">Derive and return the viewId
from
> * the current request, or the argument input by following the
> * algorithm defined in specification section JSF.7.5.2. Note that
> * unlike <code>deriveViewId()</code>, this method does not
> require that
> * a physical view be present.</p>
> *
> * <p>The default implementation of this method simply returns
> * rawViewId unchanged.</p>
> *
> * @param context the <code>FacesContext</code> for this request
> *
> * @param rawViewId the <code>viewId</code> to derive,
> *
> * @since 2.1
> */
> public String deriveLogicalViewId(FacesContext context, String
> rawViewId) {
We can revisit this decision if folks do not like this.
2. ViewDeclarationLanguage.viewExists()
> /**
> * <p class="changed_added_2_1">Tests whether a physical
resource
> * corresponding to the specified viewId exists.</p>
> *
> * <p>The default implementation uses
> * <code>ExternalContext.getResource()</code> to locate the physical
> * resource.</p>
> *
> * @param context The <code>FacesContext</code> for this request.
> * @param viewId the view id to test
> *
> * @since 2.1
> */ public boolean viewExists(FacesContext context,
> String viewId) {
Note that I did not add any new methods to
ViewDeclarationLanguageFactory. Code that needs to check for
existence can simply grab the VDL and perform the test.
3. ViewDeclarationLanguage.getId()
> /**
> * <p class="changed_added_2_1">Returns a non-null String that
> can be
> * used to identify this view declaration language.</p>
> *
> * <p>The default implementation returns the empty string.
> Subclasses
> * should override to return an id that uniquely identifies the
> * view declaration language implementation.</p>
> *
> * @since 2.1
> */
> public String getId() {
>
Nothing too exciting here. I suppose this could have been abstract,
but figured a default implementation that returns the empty string
would be acceptable.
4. ViewDeclarationLanguage id constants
> /**
> * <p class="changed_added_2_0">Identifier for the JSP view
> declaration
> * language.</p>
> *
> * @since 2.1
> */
> public final static String JSP_VIEW_DECLARATION_LANGUAGE_ID =
> "java.faces.JSP";
>
> /**
> * <p class="changed_added_2_0">Identifier for the Facelets view
> * declaration language.</p>
> *
> * @since 2.1
> */
> public final static String FACELETS_VIEW_DECLARATION_LANGUAGE_ID =
> "java.faces.Facelets";
Thoughts?
Andy
8:29 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
On 10/20/10 10:01 PM, Blake Sullivan wrote:
For ViewDeclarationLanguage.getId(), why don't we use the fully
qualified classname as the default implementation?
Sure, sounds better than "".
Andy
10:41 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Hi
Yes, the changes looks good. In the patch I proposed:
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
It was proposed this method:
+ /**
+ * <p class="changed_added_2_1">Return an Array with the configured
file
+ * extensions that can be processed by any VDL returned by this
factory</p>
+ */
+ public String[] getConfiguredExtensions()
+ {
+ return null;
+ }
The idea is just allow VDLs to define which file extensions should process,
so the algorithm on ViewHandler.deriveView() could consume it. In this way
section 7.5.2 could be fixed, and open the way other VDL to define its own
mechanism to define file extensions, usually through web config params.
Maybe this point was missing from the minimal points proposed to solve.
Now, if each VDL has its own id, it should be provided a way to retrieve the
VDL from the factory using that id and it should be provided a way to
"iterate" in a ordered way through VDL implementations, in the order they
are processed.
regards,
Leonardo Uribe
3:43 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
On 10/21/10 9:29 AM, Andy Schwartz wrote:
On 10/20/10 10:01 PM, Blake Sullivan wrote:
> For ViewDeclarationLanguage.getId(), why don't we use the fully
> qualified classname as the default implementation?
>
Sure, sounds better than "".
BTW - I uploaded a new version of my patch with this change:
https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
Andy
4:40 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Hey Leonardo -
Thanks for the additional details. I wanted to respond to the first
problem that you outline. Will follow up on the other problems soon.
(BTW, I haven't had a chance to look at your most recent email. Will do
that soon as well.)
On 10/12/10 8:20 PM, Leonardo Uribe wrote:
FIRST PROBLEM: Fix Resource Resolver
The problem happen only when suffix mapping is used.
Ah, that explains a lot. We are using prefix mappings. :-)
In few words,
When this mapping is used, it is required to check if a
physical resource exists, usually calling
ExternalContext.getResource.
Since the algorithm described on the spec does not take into
account ResourceResolver, a http 404 not found response is sent back.
I get it now. We've got two different ways to answer the question of
whether a resource exist:
1. ResourceResolver.resolveUrl(): currently only used by Facelets.
2. ExternalContext.getResource(): used elsewhere
If these return inconsistent results, we have problems. We can solve
the problem by extending our use of #1 to cases where we currently rely
on #2.
(The reference that needs to be fixed on the spec is JSF 2.0
section 7.5.2 Default ViewHandler Implementation, when it describe
the requeriments of ViewHandler.deriveViewId.)
Yep. 7.5.2 uses very generic terms - doesn't explicitly state how to
check whether a viewId actually exists.
The proposal at first view, to solve this one is add a method on
ViewDeclarationLanguageFactory called existsViewId(), so the
algorithm on
ViewHandler.deriveViewId just delegate to this one and that one
delegate to
different ViewDeclarationLanguage implementations. But it seems
better to move all
logic from section 7.5.2 ViewHandler.deriveViewId.
I am interested in what you had in mind, ie. where would we move this logic?
Here I have to mention something
I said on this discussion:
[jsr-314-open] Should the ViewDeclarationLanguage be responsible
to indicate if a
viewId can be created?
On mojarra, this is the code on
MultiViewHandler.getViewDeclarationLanguage:
public ViewDeclarationLanguage
getViewDeclarationLanguage(FacesContext context,
String viewId) {
String actualViewId = derivePhysicalViewId(context,
viewId, false);
return vdlFactory.getViewDeclarationLanguage(actualViewId);
}
Now on myfaces is this:
@Override
public ViewDeclarationLanguage getViewDeclarationLanguage(
FacesContext context, String viewId)
{
// return a suitable ViewDeclarationLanguage
implementation for the given viewId
return _vdlFactory.getViewDeclarationLanguage(viewId);
}
The difference is subtle, but very, very important. This
method is called from many
locations, but only once (from RestoreViewPhase) it is passed
the "raw" viewId.
Oh, interesting. This does seem extremely important. We've got two
types of viewIds:
- Raw: deriveViewId() logic has not yet been applied
- Derived: deriveViewId() has been applied
ViewHandler.getViewDeclarationLanguage() needs to be specific about what
type of viewId is expected. Based on the above code snippets, it looks
like Mojarra's implementation expects raw viewIds. MyFaces expects
derived viewIds. However, as you said, for the most part, Mojarra is
passing derived viewIds into ViewHandler.getViewDeclarationLanguage().
This means that Mojarra is repeatedly re-deriving viewIds on each
ViewHandler.getViewDeclarationLanguage() call. Since there can be many
calls to this method per-request, and since checking for the physical
existence of a view isn't always cheap, this seems bad.
Perhaps the spec needs to be updated to make it clear that
ViewHandler.getViewDeclarationLanguage() operates on derived viewIds?
In this case, MyFaces "derive" the physical viewId before call
getViewDeclarationLanguage
from RestoreViewPhase. In theory, we should call from
RestoreViewPhase algorithm a method
exposed by ViewHandler.
Right: ViewHandler.deriveViewId().
Getting back to the question of how to check whether a particular view
exists... I agree that at a minimum in the Facelets case we need to be
consistent about always including the ResourceResolver in this
decision. The new existence check method on
ViewDeclarationLanguageFactory() that you proposed would definitely
help. Actually, something like this would be tremendously helpful for
us here (ADF Faces), since at the moment we have logic scattered across
ResourceResolver + ExternalContext. This split approach is particularly
awkward since ExternalContext.getResource() is used more generically
than ResourceResolver - ie. ExternalContext.getResource() may be called
for arbitrary resource retrieval, whereas we are particularly interested
in view resolving.
I wanted to mention an alternate to the ViewDeclarationLanguageFactory
approach, though I am not sure whether it is an improvement. In our
case, we wouldn't mind using the ResourceResolver generically across
VDLs, ie. we wouldn't mind seeing ResourceResolver promoted to a first
class/VDL-agnostic API. Our ResourceResolver implementation is used to
serve up resources from the class path as well as from remote
repositories (eg. a database). This ability could be useful not just
for Facelets, but for arbitrary VDLs. It would be nice if we could
implement this behavior one time in a standard/portable way rather than
requiring a new solution for each VDL.
If we had access to an application-level (VDL-independent)
ResourceResolver, the JSF implementations could use this to check for
the existence of views when deriving view ids (and elsewhere) without
having to go through the ViewDeclarationLanguageFactory.
I don't think it would be especially hard to make the ResourceResolver
more general-purpose. We would likely want to add a new version of this
class outside of the Facelets packaging and possibly re-parent the
existing Facelets ResourceResolver to the new API. Or, at least, we
would want to provide the ability to transparently adopt the old
Facelets ResourceResolver to the new generic ResourceResolver.
Another small change that might be helpful... in order to answer the
question of whether or not a resource exists, we currently need to
literally cough up an URL. In our case, we might be able to optimize if
we just had to test for existence as opposed to return a reference to
the resource. Perhaps we could consider adding exists() method to the
generic ResourceResolver. By default this would just do "resolveUrl()
!= null", but this could be optimized in other implementations.
Of course, if we generalize the ResourceResolver in this way and call
this from ViewHandler.deriveViewId(), this does introduce a new
assumption: that ViewDeclarationLanguages will also use the
ResourceResolver for loading views (like Facelets does). One case where
this isn't necessarily true is the JSP ViewDeclarationLanguage, since
the JSP engine itself is responsible for loading the view. FWIW, in our
particular case, our JSP engine actually does contain resource resolving
logic that matches our ResourceResolver implementation. As such, we
would prefer to use the ResourceResolver to check for view existence
even in the JSP case, though I imagine our requirements are a bit
unusual in this area.
Thoughts?
Andy
11:33 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
Hi Andy
2010/10/13 Andy Schwartz <andy.schwartz(a)oracle.com>
Here I have to mention something
Oh, interesting. This does seem extremely important. We've got two types
of viewIds:
- Raw: deriveViewId() logic has not yet been applied
- Derived: deriveViewId() has been applied
ViewHandler.getViewDeclarationLanguage() needs to be specific about what
type of viewId is expected. Based on the above code snippets, it looks like
Mojarra's implementation expects raw viewIds. MyFaces expects derived
viewIds. However, as you said, for the most part, Mojarra is passing
derived viewIds into ViewHandler.getViewDeclarationLanguage(). This means
that Mojarra is repeatedly re-deriving viewIds on each
ViewHandler.getViewDeclarationLanguage() call. Since there can be many
calls to this method per-request, and since checking for the physical
existence of a view isn't always cheap, this seems bad.
Perhaps the spec needs to be updated to make it clear that
ViewHandler.getViewDeclarationLanguage() operates on derived viewIds?
In my opinion, yes.
In this case, MyFaces "derive" the physical viewId before call
> getViewDeclarationLanguage
> from RestoreViewPhase. In theory, we should call from RestoreViewPhase
> algorithm a method
> exposed by ViewHandler.
>
Right: ViewHandler.deriveViewId().
Right now, ViewHandler.deriveViewId() is used by NavigationHandler and in
that use case it is necessary the viewId is being checked for existence, or
in other words, if the physical resource tied to the viewId exists or not
(for preemptive navigation). Here we have two options:
- Add a method like ViewHandler.getViewDeclarationLanguageFromRawViewId
- Add another method that do the same as deriveViewId() but do not check for
viewId existence, to allow call it from Restore View Phase and do not break
existing TCK tests.
Getting back to the question of how to check whether a particular view
exists... I agree that at a minimum in the Facelets case we need to be
consistent about always including the ResourceResolver in this decision.
The new existence check method on ViewDeclarationLanguageFactory() that you
proposed would definitely help. Actually, something like this would be
tremendously helpful for us here (ADF Faces), since at the moment we have
logic scattered across ResourceResolver + ExternalContext. This split
approach is particularly awkward since ExternalContext.getResource() is used
more generically than ResourceResolver - ie. ExternalContext.getResource()
may be called for arbitrary resource retrieval, whereas we are particularly
interested in view resolving.
In theory just override or wrap ResourceResolver should be enough, and we
should prevent override ExternalContext.getResource().
I wanted to mention an alternate to the
ViewDeclarationLanguageFactory
approach, though I am not sure whether it is an improvement. In our case,
we wouldn't mind using the ResourceResolver generically across VDLs, ie. we
wouldn't mind seeing ResourceResolver promoted to a first class/VDL-agnostic
API. Our ResourceResolver implementation is used to serve up resources from
the class path as well as from remote repositories (eg. a database). This
ability could be useful not just for Facelets, but for arbitrary VDLs. It
would be nice if we could implement this behavior one time in a
standard/portable way rather than requiring a new solution for each VDL.
If we had access to an application-level (VDL-independent)
ResourceResolver, the JSF implementations could use this to check for the
existence of views when deriving view ids (and elsewhere) without having to
go through the ViewDeclarationLanguageFactory.
I agree with this one too. In theory, the VDL is responsible to build views,
so it should use some strategy to retrieve them (it is the "client"). Use a
strategy per VDL seems theorically reasonable but in practice, since each
VDL only handle files mutually exclusive with other VDL's, use a shared
ResourceResolver per all VDL is ok in my opinion.
I don't think it would be especially hard to make the
ResourceResolver more
general-purpose. We would likely want to add a new version of this class
outside of the Facelets packaging and possibly re-parent the existing
Facelets ResourceResolver to the new API. Or, at least, we would want to
provide the ability to transparently adopt the old Facelets ResourceResolver
to the new generic ResourceResolver.
In my opinion, it should be an application scope object and developers
should be able to add wrappers through faces-config.xml inside <application>
tag. It would be great!.
Anyway, there is still open the question about if the spec should allow
create wrapper per VDL from faces-config.xml. There are some use cases when
this could be helpful, like allow extend facelets an add custom "attached
objects".
Another small change that might be helpful... in order to answer the
question of whether or not a resource exists, we currently need to literally
cough up an URL. In our case, we might be able to optimize if we just had
to test for existence as opposed to return a reference to the resource.
Perhaps we could consider adding exists() method to the generic
ResourceResolver. By default this would just do "resolveUrl() != null", but
this could be optimized in other implementations.
Yes it could be, but anyway we need the method existsViewId on
ViewDeclarationLanguage (and that one will call the hypothetical method
ResourceResolver.exists() ). Why? because the VDL should be responsible to
indicate if the viewId is valid before check for existence. In the patch
proposed this check is done before call ResourceResolver stuff.
Of course, if we generalize the ResourceResolver in this way and call
this
from ViewHandler.deriveViewId(), this does introduce a new assumption: that
ViewDeclarationLanguages will also use the ResourceResolver for loading
views (like Facelets does). One case where this isn't necessarily true is
the JSP ViewDeclarationLanguage, since the JSP engine itself is responsible
for loading the view. FWIW, in our particular case, our JSP engine actually
does contain resource resolving logic that matches our ResourceResolver
implementation. As such, we would prefer to use the ResourceResolver to
check for view existence even in the JSP case, though I imagine our
requirements are a bit unusual in this area.
Thoughts?
+1 on fix all that stuff before get 2.1 out.
best regards,
Leonardo Uribe
2:23 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
+1
from me as well,
best regards,
Martin
On Fri, Oct 15, 2010 at 6:33 AM, Leonardo Uribe <lu4242(a)gmail.com> wrote:
Hi Andy
2010/10/13 Andy Schwartz <andy.schwartz(a)oracle.com>
>
> Here I have to mention something
> Oh, interesting. This does seem extremely important. We've got two types
> of viewIds:
>
> - Raw: deriveViewId() logic has not yet been applied
> - Derived: deriveViewId() has been applied
>
> ViewHandler.getViewDeclarationLanguage() needs to be specific about what
> type of viewId is expected. Based on the above code snippets, it looks like
> Mojarra's implementation expects raw viewIds. MyFaces expects derived
> viewIds. However, as you said, for the most part, Mojarra is passing
> derived viewIds into ViewHandler.getViewDeclarationLanguage(). This means
> that Mojarra is repeatedly re-deriving viewIds on each
> ViewHandler.getViewDeclarationLanguage() call. Since there can be many
> calls to this method per-request, and since checking for the physical
> existence of a view isn't always cheap, this seems bad.
>
> Perhaps the spec needs to be updated to make it clear that
> ViewHandler.getViewDeclarationLanguage() operates on derived viewIds?
In my opinion, yes.
>>
>> In this case, MyFaces "derive" the physical viewId before call
>> getViewDeclarationLanguage
>> from RestoreViewPhase. In theory, we should call from RestoreViewPhase
>> algorithm a method
>> exposed by ViewHandler.
>
> Right: ViewHandler.deriveViewId().
>
Right now, ViewHandler.deriveViewId() is used by NavigationHandler and in
that use case it is necessary the viewId is being checked for existence, or
in other words, if the physical resource tied to the viewId exists or not
(for preemptive navigation). Here we have two options:
- Add a method like ViewHandler.getViewDeclarationLanguageFromRawViewId
- Add another method that do the same as deriveViewId() but do not check for
viewId existence, to allow call it from Restore View Phase and do not break
existing TCK tests.
>
> Getting back to the question of how to check whether a particular view
> exists... I agree that at a minimum in the Facelets case we need to be
> consistent about always including the ResourceResolver in this decision.
> The new existence check method on ViewDeclarationLanguageFactory() that you
> proposed would definitely help. Actually, something like this would be
> tremendously helpful for us here (ADF Faces), since at the moment we have
> logic scattered across ResourceResolver + ExternalContext. This split
> approach is particularly awkward since ExternalContext.getResource() is used
> more generically than ResourceResolver - ie. ExternalContext.getResource()
> may be called for arbitrary resource retrieval, whereas we are particularly
> interested in view resolving.
>
In theory just override or wrap ResourceResolver should be enough, and we
should prevent override ExternalContext.getResource().
>
> I wanted to mention an alternate to the ViewDeclarationLanguageFactory
> approach, though I am not sure whether it is an improvement. In our case,
> we wouldn't mind using the ResourceResolver generically across VDLs, ie. we
> wouldn't mind seeing ResourceResolver promoted to a first class/VDL-agnostic
> API. Our ResourceResolver implementation is used to serve up resources from
> the class path as well as from remote repositories (eg. a database). This
> ability could be useful not just for Facelets, but for arbitrary VDLs. It
> would be nice if we could implement this behavior one time in a
> standard/portable way rather than requiring a new solution for each VDL.
>
> If we had access to an application-level (VDL-independent)
> ResourceResolver, the JSF implementations could use this to check for the
> existence of views when deriving view ids (and elsewhere) without having to
> go through the ViewDeclarationLanguageFactory.
>
I agree with this one too. In theory, the VDL is responsible to build views,
so it should use some strategy to retrieve them (it is the "client"). Use a
strategy per VDL seems theorically reasonable but in practice, since each
VDL only handle files mutually exclusive with other VDL's, use a shared
ResourceResolver per all VDL is ok in my opinion.
>
> I don't think it would be especially hard to make the ResourceResolver
> more general-purpose. We would likely want to add a new version of this
> class outside of the Facelets packaging and possibly re-parent the existing
> Facelets ResourceResolver to the new API. Or, at least, we would want to
> provide the ability to transparently adopt the old Facelets ResourceResolver
> to the new generic ResourceResolver.
>
In my opinion, it should be an application scope object and developers
should be able to add wrappers through faces-config.xml inside <application>
tag. It would be great!.
Anyway, there is still open the question about if the spec should allow
create wrapper per VDL from faces-config.xml. There are some use cases when
this could be helpful, like allow extend facelets an add custom "attached
objects".
>
> Another small change that might be helpful... in order to answer the
> question of whether or not a resource exists, we currently need to literally
> cough up an URL. In our case, we might be able to optimize if we just had
> to test for existence as opposed to return a reference to the resource.
> Perhaps we could consider adding exists() method to the generic
> ResourceResolver. By default this would just do "resolveUrl() != null",
but
> this could be optimized in other implementations.
>
Yes it could be, but anyway we need the method existsViewId on
ViewDeclarationLanguage (and that one will call the hypothetical method
ResourceResolver.exists() ). Why? because the VDL should be responsible to
indicate if the viewId is valid before check for existence. In the patch
proposed this check is done before call ResourceResolver stuff.
>
> Of course, if we generalize the ResourceResolver in this way and call this
> from ViewHandler.deriveViewId(), this does introduce a new assumption: that
> ViewDeclarationLanguages will also use the ResourceResolver for loading
> views (like Facelets does). One case where this isn't necessarily true is
> the JSP ViewDeclarationLanguage, since the JSP engine itself is responsible
> for loading the view. FWIW, in our particular case, our JSP engine actually
> does contain resource resolving logic that matches our ResourceResolver
> implementation. As such, we would prefer to use the ResourceResolver to
> check for view existence even in the JSP case, though I imagine our
> requirements are a bit unusual in this area.
>
> Thoughts?
>
+1 on fix all that stuff before get 2.1 out.
best regards,
Leonardo Uribe
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
7:58 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
5176
days inactive
5185
days old
jsr-314-open-mirror@lists.jboss.org
16 comments
5 participants
participants (5)
-
Andy Schwartz -
Blake Sullivan -
Ed Burns -
Leonardo Uribe -
Martin Marinschek