[jsr-314-open-mirror] [jsr-314-open] [545-VisitHints] proposal (was: Re: Tree visit hints [Was: ADMIN: Final list of issues for JSF 2.0 and actions for each])
2:28 p.m.
>>>> On Thu, 10 Jun 2010 13:49:32 -0400, Andy Schwartz
<andy.schwartz(a)oracle.com> said:
AS> Since my preferred solution (ie. a standard visit hint) doesn't seem to
AS> be possible at the moment, I have reached the point where I am wondering
AS> whether we could consider uglier, non-standard, temporary solutions.
AS> For example, one option might be for the JSF implementations to
AS> introduce a flag hanging off of the FacesContext attribute map that
AS> would serve the same purpose as VisitHint.SKIP_ITERATION, at least until
AS> we can get the standard solution in place for 2.1.
As the interim mojarra technical lead, I agree with this. Andy, if you
could attach a patch to [VisitHints-545] [1] that does this for Mojarra,
I'll give it top attention.
Ed
[1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=545
--
| edburns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 21 Work Days Til JSF 2.1 Milestone 1
5:14 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [545-VisitHints] proposal (was: Re: Tree visit hints [Was: ADMIN: Final list of issues for JSF 2.0 and actions for each])
2010/6/10 Ed Burns <edward.burns(a)oracle.com>
>>>>> On Thu, 10 Jun 2010 13:49:32 -0400, Andy
Schwartz <
andy.schwartz(a)oracle.com> said:
AS> Since my preferred solution (ie. a standard visit hint) doesn't seem to
AS> be possible at the moment, I have reached the point where I am
wondering
AS> whether we could consider uglier, non-standard, temporary solutions.
AS> For example, one option might be for the JSF implementations to
AS> introduce a flag hanging off of the FacesContext attribute map that
AS> would serve the same purpose as VisitHint.SKIP_ITERATION, at least
until
AS> we can get the standard solution in place for 2.1.
As the interim mojarra technical lead, I agree with this. Andy, if you
could attach a patch to [VisitHints-545] [1] that does this for Mojarra,
I'll give it top attention.
I'll keep an eye on this issue to include it on myfaces too.
Leonardo
Ed
[1]
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=545
--
| edburns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 21 Work Days Til JSF 2.1 Milestone 1
5:45 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [545-VisitHints] proposal
2010/6/10 Andy Schwartz <andy.schwartz(a)oracle.com>
On 6/10/10 6:14 PM, Leonardo Uribe wrote:
2010/6/10 Ed Burns <edward.burns(a)oracle.com>
>
> As the interim mojarra technical lead, I agree with this. Andy, if you
> could attach a patch to [VisitHints-545] [1] that does this for Mojarra,
> I'll give it top attention.
>
>
I'll keep an eye on this issue to include it on myfaces too.
Great, thanks guys!
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". 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";
Leonardo Uribe
Andy
Leonardo
> Ed
>
> [1]
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=545
>
> --
> | edburns(a)oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
> | 21 Work Days Til JSF 2.1 Milestone 1
>
3:16 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [545-VisitHints] proposal
Hi Leo
I think (and it is my personal opinion) it is preferred to use
"javax.faces.visit.SKIP_ITERATION". 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:
yes, sure - Andy just meant if we can do this if it is not yet in the
specification. I would guess we should do so, so that people can move
smoothly to 2.1.
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";
that should be changed as well!
best regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
10:49 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [545-VisitHints] proposal
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/showattachm...
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
5102
days inactive
5106
days old
jsr-314-open-mirror@lists.jboss.org
5 comments
4 participants
participants (4)
-
Andy Schwartz -
Ed Burns -
Leonardo Uribe -
Martin Marinschek