On Thu, 23 Dec 2004 18:04:18 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
> Craig McClanahan wrote:
> > 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.
I guess I'm not seeing the advantage of having a controller (in the
sense that we've traditionally used talking about Struts or Cocoon) in
*front* of JSF's controller. In a very simplistic sense, there are
three kinds of requests in the world:
* UI State Change (example: tree control node open/close, where
the component's state is managed server side). Should be handled
by the view tier technology (JSF in this scenario, which Shale
puts in front).
* Form Submit to be validated (example: typical of what Struts
form processing ins about). Should be handled by the application
tier that enforces such things (in Shale, this is done by a combination
of the JSF validators and an upcoming integration of Commons
Validator, all managed transparently by the JSF lifecycle, including
redisplay of the input page if validation fails.
* Validated form submit to be processed by business logic (example:
what we use actions for in Struts; in JSF/Shale this is the invocation
of the action method bound to your submit button).
There's still room for some overall per-request processing for things
like enforcing authentication, performance logging, etc. That can all
be handled with a Filter (Shale's filter predefines "before" and
"after" chains that you can use to decorate the basic functionality.
I guess I don't see why I need anything else as a controller -- with
the possible exception of managing dialogs that are "longer than a
request and shorter than a session". What I've got so far is
conceptually pretty similar to what you can do today by sharing a
single form bean across multiple pages; the reason it's not posted yet
is I haven't made the "remove the session object when you leave the
dialog" part quite elegant enough yet.
>
> 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");
>
Hmm ... I'm not sure cascading if's are all that much easier to
understand and maintain than the corresponding configuration of this
with JSF navigation rules :-).
> 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.
That would definitely be a value add. We need to experiment to see
how much value.
>
> Don
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
