[jsr-314-open-mirror] [jsr-314-open] [545-VisitHints] proposal

[Andy Schwartz]

On 6/10/10 6:45 PM, Leonardo Uribe wrote:
>
>
>
>     BTW, any thoughts on what an acceptable name, or, at least, prefix
>     would be?  The VisitHint will be SKIP_ITERATION.  Can we go with
>     something like "javax.faces.visit.SKIP_ITERATION" - or do we need
>     to stay away from the "javax.faces" prefix since this won't be
>     part of the specification?
>
>
> I think (and it is my personal opinion) it is preferred to use 
> "javax.faces.visit.SKIP_ITERATION".

I like this name as well, though I would be okay with just about any 
name that we can get the JSF implementations to agree on. :-)

I have attached a (Mojarra-specific) patch to issue 545 that implements 
the desired behavior using this name.  See:

https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachment.cgi/246/skip-iteration-hack.patch

BTW, one thing to keep in mind with this "fix"... this should be viewed 
as a temporary workaround only.  One thing that I particularly dislike 
about this workaround is that it does not work well with nested tree 
visits since the FacesContext is shared across visits.  The correct 
solution is to add a new VisitHint value.  This would allow the 
iteration behavior to be controlled on a per-visit basis without 
complicating nested visits.   I am hoping that we can get the correct 
fix in as early as possible, ideally as soon as we've got 2.1 branches.


> If some user needs to override visitTree (example: an alternate 
> implementation of UIData), he/she should be aware of this facesContext 
> attribute. The only point on the api that does not use javax.faces for 
> a facesContext attribute is this one:
>
> public abstract class FaceletContext extends ELContext
> {
>     // TODO: REPORT this aberration to the EG
>     public static final String FACELET_CONTEXT_KEY = 
> "com.sun.faces.facelets.FACELET_CONTEXT";

Oh.  Woops.  :-)

We should fix this, though, in the future... shouldn't we expose a 
type-safe utility method for this sort of thing rather than a named key?

Andy