On 12/21/05, tony kerz <[EMAIL PROTECTED]> wrote:
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
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
