On Thu, 23 Dec 2004 22:24:28 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > I think, Don, that this "integration" is a bit smoke and mirrors > Really what the integration is, if I understand it right, is just a > switch to use either JSF or Struts. They really cannot work together > because JSF has a page based controller which is inconsistent with > everything Struts as we know does.
Sorry Jack, you don't have it right at all. The current integration library absolutely lets you use JSF components in an application based on Struts 1.1 or 1.2. Plus, far from being smoke and mirrors, the code actually exists too -- unlike some proposed approaches :-). http://svn.apache.org/builds/struts/nightly/struts-faces/ Of course, this approach doesn't leverage anything of JSF other than the visual components, but that's OK if it floats your boat. Don's question was primarily around whether you put JSF in front of, or behind, a flow-through controller (the page based part isn't really the important issue -- the part about wanting to be in front, and processing *all* requests first, is the key one). The integration library currently puts JSF in front (for user interface events only), which I believe is the better architecture -- a particular request penetrates into the system only as far as it makes sense. There's no reason, for example, for any business logic action to get involved in a purely visual change like expanding or contracting a tree node. Putting JSF in front lets that happen; the current Struts architecture doesn't. As for the future, the queston that Struts 1.x developers need to ask ourselves is "what's the value add of a flow-through controller" in a JSF environment. Others have already shown, for example, that you can use Tiles and Commons Validator directly with JSF (without using the Struts controller architecture) -- and these are capabilities I already know how to integrate into Shale. Servlet Filters let you do all the overall per-request type things you might want to do; no extra infrastructure is needed for overall control things like "is the user logged in" checking. It's also quite pleasant to be done with form beans (JSF components already do the stuff we used to need them for); to have the logic to set up a page and process it's input next to each other instead of in two actions that have to be chained; to not need "configuration beans" at all; to be able to manage multi-request dialogs more gracefully (stay tuned for a Shale example next week); and to be able to use JSF components from multiple libraries; but I digress ... > > Jack > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
