<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hey Leonardo -<br>
<br>
On 10/15/10 12:33 AM, Leonardo Uribe wrote:<br>
<blockquote
cite="mid:AANLkTi=e-SfdXPvqp9eFVPifSyrSOWBizqZ7kN51_bXf@mail.gmail.com"
type="cite"><br>
<div class="gmail_quote">2010/10/13 Andy Schwartz <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:andy.schwartz@oracle.com">andy.schwartz@oracle.com</a>></span><br>
<br>
<div><br>
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:<br>
<br>
- Add a method like ViewHandler.getViewDeclarationLanguageFromRawViewId<br>
- 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.<br>
</div>
</div>
</blockquote>
<br>
I prefer the second form, since this would allow us to have a single
bottleneck through which the VDL is retrieved
(ViewHandler.getViewDeclarationLanguage()).<br>
<br>
Though I am still a bit confused about the nature of the TCK tests that
are failing. Does the TCK require that a view can be restored in the
case where no physical resource is associated with the view? If we
make the changes that we have been discussing relating to how we check
for view existence, would this help the tests pass, or are there still
cases where restore view needs to handle viewIds that fail the
existence check?<br>
<br>
In any case, adding a new ViewHandler method that performs
deriveViewId() logic without the final existence check seems
reasonable. (Note that in the suffix case, deriveViewId() will still
perform existence checks as it tests out various configured file
extensions.)<br>
<br>
<blockquote
cite="mid:AANLkTi=e-SfdXPvqp9eFVPifSyrSOWBizqZ7kN51_bXf@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
<br>
</blockquote>
<div><br>
In theory just override or wrap ResourceResolver should be enough, </div>
</div>
</blockquote>
<br>
Right.<br>
<br>
<blockquote
cite="mid:AANLkTi=e-SfdXPvqp9eFVPifSyrSOWBizqZ7kN51_bXf@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>and we should prevent override ExternalContext.getResource().<br>
</div>
</div>
</blockquote>
<br>
Well, maybe not prevent - should still be allowed - but hopefully this
won't be necessary anymore.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTi=e-SfdXPvqp9eFVPifSyrSOWBizqZ7kN51_bXf@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
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.<br>
<br>
</blockquote>
<div><br>
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 <span id="result_box"
class="short_text" lang="en"><span style="" title="">mutually
exclusive </span></span>with other VDL's, use a shared
ResourceResolver per all VDL is ok in my opinion.<br>
</div>
</div>
</blockquote>
<br>
Cool. I don't think this is a hard requirement, but would simplify
life for anyone who wants to tweak view resolving/loading.<br>
<br>
<blockquote
cite="mid:AANLkTi=e-SfdXPvqp9eFVPifSyrSOWBizqZ7kN51_bXf@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
<br>
</blockquote>
<div><br>
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!.<br>
</div>
</div>
</blockquote>
<br>
I agree.<br>
<br>
<blockquote
cite="mid:AANLkTi=e-SfdXPvqp9eFVPifSyrSOWBizqZ7kN51_bXf@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
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".</div>
</div>
</blockquote>
<br>
Definitely. I mentioned a case where I very much need this in my
previous email. My guess is that by default the VDL for JSP will
implement the view existence check by calling
ExternalContext.getResource() - always been this way. However, in my
case, I have the ability to execute JSPs off of the classpath or even
JSPs loaded from a remote repository, so I will want to update the view
existence check to reflect this. In theory I should be able to do this
by providing my own ViewDeclarationLanguageFactory that creates a
wrapper around the JSP VDL, allowing me to insert my own existence
checking logic.<br>
<br>
The problem: I specifically want to wrap the JSP VDL and not any
other. However, with our current APIs, my
ViewDeclarationLanguageFactory has no way to know which VDL *is* the
JSP VDL. A simple way to solve this would be to:<br>
<br>
- Introduce the notion of a VDL id, ie. add a getId() (or
getViewDeclarationLanguageId()) method to ViewDeclarationLanguage.<br>
- Specify standard ids for the VDLs provided by the specification (eg.
"javax.faces.Jsp", "javax.faces.Facelets")<br>
<br>
This would allow ViewDeclarationLanguageFactory implementations to
target individual VDLs. It would also provide a starting point from
which we could build a declarative solution, ie. instead of
implementing a ViewDeclarationLanguageFactory to wrap a specific VDL,
it would be nice to be able to do something like:<br>
<br>
<view-declaration-language><br>
<view-declaration-language-id>javax.faces.Jsp</view-declaration-language-id><br>
<view-declaration-language-class>my.bizarre.vdl.WrapperForJspOnly</view-declaration-language-class><br>
</view-declaration-language><br>
<br>
To achieve the same behavior.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTi=e-SfdXPvqp9eFVPifSyrSOWBizqZ7kN51_bXf@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> <br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
<br>
</blockquote>
<div><br>
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.<br>
</div>
</div>
</blockquote>
<br>
I like the idea of having the existence check on
ViewDeclarationLanguage. Two suggestions:<br>
<br>
- Let's call this viewExists() instead of existsViewId().<br>
- Let's not expose this on ViewDeclarationLanguageFactory.<br>
<br>
The second suggestion would mean that we would replace code like this:<br>
<br>
<blockquote type="cite"> if (vdlFactory.existsViewId(context, viewId))
{ ... }<br>
</blockquote>
<br>
With:<br>
<br>
<blockquote type="cite"> ViewDeclarationLanguage vdl =
getViewDeclarationLanguage(viewId)<br>
if (vdl.viewExists(context, viewId)) { ... }<br>
</blockquote>
<br>
These achieve the same result, but the second approach keeps the
ViewDeclarationLangaugeFactory contract/implementation as simple as
possible.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTi=e-SfdXPvqp9eFVPifSyrSOWBizqZ7kN51_bXf@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Thoughts?<br>
<font color="#888888"><br>
</font></blockquote>
<div><br>
+1 on fix all that stuff before get 2.1 out.<br>
</div>
</div>
</blockquote>
<br>
<br>
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.<br>
<br>
These seem to be the minimal requirements:<br>
<br>
1. The ViewHandler.getViewDeclarationLanguage() should be clear that it
expects "derived" view ids.<br>
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.<br>
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.<br>
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.<br>
<br>
In addition, these requirements would be good to address:<br>
<br>
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.<br>
6. Allow #4 to be accomplished declaratively via faces-config.xml.<br>
<br>
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. :-)<br>
<br>
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.<br>
<br>
Andy<br>
<br>
<blockquote
cite="mid:AANLkTi=e-SfdXPvqp9eFVPifSyrSOWBizqZ7kN51_bXf@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
best regards,<br>
<br>
Leonardo Uribe <font color="#888888"><br>
</font></div>
</div>
<br>
</blockquote>
<br>
</body>
</html>