On 12/22/05, Tony Kerz <[EMAIL PROTECTED]> 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.
Maybe we've both been obsessing over solving this problem with JSF navigation :-).
Craig
thanks craig,
you bring good points about confusion being proportional to the number
of technologies applied.
in this particular case, the mechanism i'm trying to construct is a
relatively familiar one where a user is confirming a registration to a
website by clicking a url link in a registration confirmation email.
kind of an oddball when compared to the rest of the application which
should be more comfortable with standard jsf.
the query string will contain the id of the user attempting to confirm
their registration, and i have to look up that id in a database to make
sure it exists and mark it as confirmed if so.
my original tactic was to perform this logic in a getter method of a
message type attribute being displayed on some confirmation page.
if i incurred an error, i would just return an error message, otherwise
i would return a "congratulations" message, but i already had a strategy
for handling errors from action methods which involved navigating to a
dedicated error page based on outcome and it bugged me that i had to use
a different mechanism here.
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.
ok, now that i've fessed up, you can come to a more informed decision as
to whether i'm obsessing ;)
Maybe we've both been obsessing over solving this problem with JSF navigation :-).
Craig
Craig McClanahan wrote:
>
>
> On 12/21/05, *tony kerz* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> right, i'm looking for the process to be initiated by a url
> punched into
> a browser, not a user clicking a <h:commandButton> or <h:commandLink>
> control.
>
> as i can have a url drop directly into an action and use
> mapping.findForward(outcome) to use the struts configuration
> navigation
> rules to direct to the next page.
>
> is there an analogy to mapping.findForward() that could be invoked
> in a
> controlling servlet?
>
> seems like it could be useful to have a servlet which you could
> pass in
> something like "managedBeanName.actionMethodName" in as a
> parameter and
> have it do the right thing.
>
>
> You can always use "for real" Struts navigation, if you like, by using
> JSF in conjunction with the Struts-Faces integration library. But ...
>
> That all being said, I wonder if you might be obsessing over a low
> level implementation detail, rather than deriving an architecture from
> application requirements. One of the things I have most enjoyed about
> using JSF is freedom from ever having to wire URLs together with Java
> or _javascript_ code ... I can just focus on the task at hand.
> Requirements for bookmarkability complicates that scenario a bit, in
> that you do need to care what kinds of URLs get emitted. But
> redirects, in combination with a custom navigation handler, would seem
> more elegant to me.
>
> One thing I would tend to avoid, however, is a plan to mix both
> JSF-style and Struts-style navigation into the fundamental
> architecture of my application -- that's just asking for confusion
> later on in your application's lifetime, when you have to decide (for
> each new bit of functionality) whether you should do it the "JSF way"
> or the "Struts way". Target doing things one way or the other -- the
> only place for having both is when you are transitioning from one
> technology to the other, and you don't have time to convert the entire
> application at once.
>
> (NOTE - to provide application functionaity on an initial processing
> of a URL, use Shale's ViewController as mentioned on the corresponding
> thread in the Struts user mailing list.)
>
> Craig
>
