On 12/26/05, tony kerz <[EMAIL PROTECTED]> wrote:
Presuming you are in the middle of a JSF request, so there is already a FacesContext object, this is pretty straightforward:
FacesContext context = FacesContext.getCurrentInstance();
String action = "" // The action you are pretending was executed
String outcome = "success"; // The logical outcome you are pretending was returned
NavigationHandler nh =
context.getApplication().getNavigationHandler();
nh.handleNavigation(context, action, outcome);
The interesting part of the problem is ensuring that you are inside a JSF request. This happens automatically if you use a URL that is mapped to FacesServlet. If you are not, you can "fake" it by doing exactly what FacesServlet does to set up a JSF request ... the easiest way to figure that out is to look at the FacesServlet implementation in either MyFaces or the JSF RI ... its about five lines of code to establish a new FacesContext, turning a non-JSF request into a JSF request.
You'd likely be better off creating a custom component that creates the kind of _javascript_ you need. That way, any dependencies you will have when decoding the incoming request can be reflected in the encoding calls inside the same Renderer. By the way, this is exactly the reason that a Renderer has both decode and encode behavior ... dependencies between the two kinds of processing, for the same component, are very common, and should be encapsulated together.
If you look at the renderer code for the standard submit button, you'll see exactly the same sort of cross dependency ... the decoding logic has to know what rules the encoding logic followed, and vice versa.
Craig
thanks for the suggestions.
- i don't think i need any jsf facilities during processing,
so your first suggestion would be most pragmatic.
- just in case i end up needing to go the second route though, for this
or something else, how does one "call the standard navigation handler
manually"?
Presuming you are in the middle of a JSF request, so there is already a FacesContext object, this is pretty straightforward:
FacesContext context = FacesContext.getCurrentInstance();
String action = "" // The action you are pretending was executed
String outcome = "success"; // The logical outcome you are pretending was returned
NavigationHandler nh =
context.getApplication().getNavigationHandler();
nh.handleNavigation(context, action, outcome);
The interesting part of the problem is ensuring that you are inside a JSF request. This happens automatically if you use a URL that is mapped to FacesServlet. If you are not, you can "fake" it by doing exactly what FacesServlet does to set up a JSF request ... the easiest way to figure that out is to look at the FacesServlet implementation in either MyFaces or the JSF RI ... its about five lines of code to establish a new FacesContext, turning a non-JSF request into a JSF request.
- just for kicks i tinkered with a _javascript_ hack to call an action
method, and this seems to work although it has the drawbacks of:
(a) having to specify the button id as named by the jsf implementation
(i.e. <form name>:<button name>) and i don't think this naming
convention is part of the spec and therefore not portable and
You'd likely be better off creating a custom component that creates the kind of _javascript_ you need. That way, any dependencies you will have when decoding the incoming request can be reflected in the encoding calls inside the same Renderer. By the way, this is exactly the reason that a Renderer has both decode and encode behavior ... dependencies between the two kinds of processing, for the same component, are very common, and should be encapsulated together.
If you look at the renderer code for the standard submit button, you'll see exactly the same sort of cross dependency ... the decoding logic has to know what rules the encoding logic followed, and vice versa.
Craig
(b) having the dummy form flash momentarily although you might be able
to give the button zero size or something so that it is a completely
blank screen
<%@ include file="/include/taglibs.jsp"%>
<body > <f:view>
<h:form id="dummy">
<h:commandButton id="submit" action="" />
</h:form>
</f:view>
</body>
- as an aside, i originally tried document.dummy.submit() for onload,
but it resulted in an infinite loop. i'm sure an artifact of the clever
way jsf is implemented, but unexpected just the same.
Craig McClanahan wrote:
>
> Since you don't care about restoring a JSF component tree on this
> particular page, it might be simpler to not worry about using JSF at
> all to process the request:
>
> * Create a standalone servlet mapped to the front of the URL
> on the confirmation email.
>
> * It would use standard servlet API facilities to pull the information
> it needs out of the URL, and do the database lookup/update.
>
> * It would navigate by doing a RequestDispatcher.forward () to
> either "/congratulations.faces" or "/problem.faces".
>
> If you did want to use JSF facilities in the processing (say, you
> wanted to evaluate value bindings or create managed beans), an
> alternative would be to use a phase listener for the "Before Restore
> View" event, intercepting the incoming request before the standard
> processing lifecycle. Your handler could do the database update, then
> call the standard navigation handler manually based on the outcome.
>
