You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2004/12/23 21:31:19 UTC
[struts-faces] JSF integration into Struts
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.
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?
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.
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.
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?
Don
---------------------------------------------------------------------
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 Matthias Wessendorf <ma...@matthias-wessendorf.de>.
> 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
Nice to hear! Is a thing, that will be *public* next week?
Then I will play a bit with Shale.
> 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
yes, we are ;-) sounds nice!
> components from multiple libraries; but I digress ...
no, you don't ... it is still interessting
but perhaps a bit OT ... ;-)
> Craig
Matthias
> ---------------------------------------------------------------------
> 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
Re: [struts-faces] JSF integration into Struts
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 23 Dec 2004 22:24:28 -0800, Dakota Jack <da...@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [struts-faces] JSF integration into Struts
Posted by Dakota Jack <da...@gmail.com>.
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.
Jack
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.
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
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
Re: [struts-faces] JSF integration into Struts
Posted by Craig McClanahan <cr...@gmail.com>.
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