On Thu, 23 Dec 2004 12:31:19 -0800, Don Brown <[EMAIL PROTECTED]> wrote:<snip />
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 what I have in mind is the JSF integration approach Cocoon takes. Every request enters Cocoon, then certain pipelines can choose to hand the request off to JSF. Conceptually, I think it is a better fit with the advantages of the respective frameworks. Cocoon and Struts excel at a request-based approach, so it is a natural fit for them to be the controller for all requests, JSF or not. JSF, as an event-based framework, is a fine solution for components or complex, event-based pages.
The end game here would be to make Struts a universal controller implementation that could front-end JSF, Cocoon (as it can do now with the Struts Cocoon plugin), continuations-based frameworks, or any other more specialized controller implementation. IMO, chain is great for a universal controller backbone, but poor/too-generic for an application-level controller framework. Not every request/workflow might be appropriate for JSF, but by putting it behind Struts, the developer has the option how best to handle it.
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).
Actually, I think continuations really excel at workflows that involve branches, because the power of a full scripting language is more capable of handling such complex logic, as opposed to say a workflow system based on XML.
All continuations really do is help you script the sequence of pages and connect them into a logical process. In your example, the logic for pulling authentication information out of cookies or a form POST would be extracted to a Java class or helper Javascript method for simpler apps. Continuations would help with the multistep process of collecting information. Probably, it would go something like this:
if (!loginThroughCookies()) {
while (true) {
showPageAndWait("login");
if (context.requestParams["register"] != null) {
showPageAndWait("login1");
if (context.requestParams["cancel"] != null) {
continue;
}
showPageAndWait("login2");
if (context.requestParams["cancel"] != null) {
continue;
} else {
registerUser();
}
} else if (loginThroughForm()) {
break;
}
}
}// This step could also call the mainMenu function to start that
// workflow
showPageAndWait("mainMenu");Keep in mind, I'm very new at continuations, so I'm sure someone more knowledgable could make something simplier. One improvement is if you use the Wizard framework I created for struts-flow, it would be even simpler because the wizard framework would automatically handle HTML form button clicks that went to the previous step.
Don
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
