You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Craig McClanahan <cr...@gmail.com> on 2004/12/23 22:03:26 UTC
Re: [struts-faces] JSF integration into Struts
On Thu, 23 Dec 2004 12:31:19 -0800, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [struts-faces] JSF integration into Struts
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 23 Dec 2004 18:04:18 -0800, Don Brown <mr...@twdata.org> wrote:
> Craig McClanahan wrote:
> > On Thu, 23 Dec 2004 12:31:19 -0800, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [struts-faces] JSF integration into Struts
Posted by Don Brown <mr...@twdata.org>.
Craig McClanahan wrote:
> On Thu, 23 Dec 2004 12:31:19 -0800, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org