Mike Kienenberger wrote:
It's not hard to create a FacesContext instance. I do this in my
servlet filters.
http://www.thoughtsabout.net/blog/archives/000033
Yes, but in a PhaseListener constructor there are no
ServletRequest/ServletResponse objects, so creating a faces context is
less trivial; mock instances need to be created.
It's personal preference, but having one hardcode bean seems better
than iterating through registered phase listeners and pushing values
to them.
Depends on where the phase listener is. If it's in a library (as mine
is) then hard-wiring a bean name that webapps using that lib must define
is not nice. Allowing the using webapp to find and configure the phase
listener is more elegant. Obviously if the phase-listener is part of the
webapp then a hard-wired bean name is less of an issue..
I'd also prefer your beforePhase flag method over constructing a
FacesContext.
As you say, if you only need to fetch the data once, it's
?? missing something :-) ??
On 12/7/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
It should be possible to get the Application object directly rather than
via a FacesContext:
Application app = ((ApplicationFactory)
FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY))
.getApplication();
Arrgh. Yes, this is possible. However then evaluating the value binding
required a FacesContext anyway:
> To borrow Jeff's example:
>
> FacesContext context = FacesContext.getCurrentInstance();
> ValueBinding binding =
> context.getApplication().createValueBinding("configBean");
> return (ConfigBean)binding.getValue(context);
Actually, I would prefer using resolveVariable over createValueBinding,
but that also needs a context param:
NeededBean neededBean
= (NeededBean) facesContext.getApplication()
.getVariableResolver().resolveVariable(facesContext,
"neededBean");
So creating a FacesContext is indeed needed, which means mocking
ServletRequest/ServletResponse again...
Regards,
Simon
