On Thu, 23 Dec 2004 12:31:19 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > Pardon the ignorance, but as I understand it, the struts-faces > integration library allows Struts components to be executed within the > JSF framework. JSF handles the request, then using special adapters, > actions are executed when desired.
I would word it the other way around ... the integration library allows you to use JSF components in the Struts framework. When using this combination, you would continue to use Struts facilities for things like navigation and validation, rather than the corresponding JSF facilities. > > If that is correct, would it be possible to implement JSF within Struts > chain? Could a JSF implementation be decomposed into chain commands, > and therefore allow the user to mix and match? You'd have to replace the standard implementation of JSF's Lifecycle API while still ensuring that the JSF based functioning happens in the correct order. To my mind, it's easier to decompose what Struts does and bolt it onto JSF (basically the direction Shale is taking) versus the other way. > > I guess where I'm going with this is one of the huge advantages of an > event-based view framework like JSF is the ability to have > self-contained, complex components. On the other hand, I think > event-based approaches are poor at handling complex workflows as code > has to be split up into different event methods. It seems like a > perfect marriage would be event-based framework for the components, but > continuations-based framework for application events and actions. Stay tuned next week for a Shale checkin that addresses the complexity of managing dialogs -- I've made some good progress fleshing that out. Continuations are definitely a good way to deal with serial workflows like a wizard dialog, and I'd like to see us continue to explore that avenue -- it's just not (yet?) obvious to me that they are optimal for workflows with lots of branches in them. Consider, for example, a "dialog" for handling authentication at a portal that also allows self-registration and "remember me" cookies. The various paths through this logic are essentially the same as the front parts of MailReader (up to where you get to the main menu), plus a bypass branch if the user's cookie is still there. For extra fun, assume that the process of collecting user profile info takes multiple screens, and that the user might at any point cancel the whole thing (meaning no updates should show up in any database). > > By decomposing JSF into commands, JSF could handle events from its > components, but application processes would be handled on a request > basis with Action's, continuation-capable flows, or whatever. I suppose > this would not be a real JSF implementation since JSF concepts like > navigation wouldn't be used. Yep ... in that respect it would be like the current integration library, bypassing that feature of JSF. Or, you could plug the continuation resumption thing into the JSF NavigationHandler, perhaps. > > Perhaps this is what Shale is trying to, or it is just flatout > impossible, I just thought I'd throw the idea out there. I like the > chain-based request processing model of Struts, but want to take > advantage of JSF components. Does this make any sense? Definitely some ideas worth pursuing. I'd like to understand how one would model a complex workflow (such as the one described above) with continuations. > > Don > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
