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.
ok, now that i've fessed up, you can come to a more informed decision as
to whether i'm obsessing ;)
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
