Re: Workflow for Struts

[Vic Cekvenich]

Ted Husted wrote:
The thing I keep coming back to is whether workflows are a Struts 
problem."
Agree! that Workflow, PageFlow are not a Struts... or a problem.

In greenscreens(Cobol), we had (work)flow, chose menu 1-12, then 1-6, 
etc. The programers is in control of next step.
Web is event oriented. The user is in control, programer has to code 
defensive. We just receive events and handle.
Ex: User start to fill out credit info, then browses to Amazon, Google, 
then comes back.

From business side, being process centric is bad. Info, or model, or 
data centric is better, since the business process changes and needs to 
be dynamic.



my 02 c.
.V


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Workflow for Struts

[Paul_T_Smith]

Sorry I keep uploading the same message, having some problems with my
email:-) Anyway, I downloaded Tomcat 4.1.27 and deployed the war file and it
worked ok. Maybe you need to delete you work directory so that it loads the
new files. I had some trouble with that initially.

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] 
Sent: Sunday, August 03, 2003 11:58 AM
To: Struts Developers List
Subject: Re: Workflow for Struts

The thing I keep coming back to is whether workflows are a Struts 
problem. I would agree that multipage form *wizards* that collect input 
are definitely a Struts problem. But, I can't but help wonder whether 
more advanced types of workflows would be better defined as part of a 
business application controller -- rather than a presentation front 
controller, like Struts. (Or, presentation service-to-worker controller, 
if you are a J2EE Blueprints follower.)

AFAIK, there really aren't any open-source business application 
controller frameworks "out there" now, and Struts often ends up filling 
this void. Before we talk about extending Struts so that it encroaches 
on business application space, perhaps we should consider whether 
"Struts is enough".

What I'm thinking is that below Struts there should be a pure business 
application controller framework. It would have all the same hallmarks 
as Struts, such as input helpers, locations, handlers, and message 
resources. But, these would all have pure signatures, free of web and 
servlet semantics. Essentially, Struts without HTTP.

While things like "wizards" would live in the Struts layer, things like 
"workflows" would live in this business layer.

Struts could work as an extension of the business framework. Struts 
gathers up the input parameters, and other user gestures, and passes 
them to the business framework. The business framework then passes back 
dispatch tokens (like "success"), messages, and value objects (or 
collections of value objects).

The business application controller decides whether to go to "success", 
"failure", or "outForBeer". Struts fills in the path to the web 
application resource representing each token. Likewise, the business 
application controller passed back keys to the message resources, and 
Struts renders the localized versions. And, of course, the business 
application controller passes back objects with dynamic data to display, 
and Struts sends them to the server pages that can render them.

This is exactly what many (or even most) of us are doing now, except 
that we are all rolling our own proprietary solutions. I've worked with 
some companies that have already designed full-blown business layer 
frameworks such as this, based on the Struts architecture.

It may be time to take the hint and develop an open source business 
application controller framework where we can "share the wealth" as we 
have done with struts. Essentially, the idea would be to take Struts and 
abstract-out the web and servlet semantics. Where Struts might use an 
Action with an

   ActionForward 
execute(ActionMapping,ActionForm,SerlvetRequest,ServletResponse),

the business layer framework would use a Handler with a

   Location process(Dispatcher,Helper,Context)

Struts then becomes a HTTP/Servlet extension of the business application 
controller framework. Where many developers are now writing "Actions", 
they could write web-semantic-free "Handlers" instead. Action classes 
would still be available when you really need to use web semantics, but 
otherwise, development effort can be put into web-free Handler classes. 
When web-semantics are not required, a single "gateway" Action can 
provide an adapter between Struts and the business layer framework. This 
moves most of the hard-core development completely out of Action classes 
and into platform-independant "POJO" classes.

I think the overall Struts architecture works great for a lot of people 
(including me!). But when it comes to putting development effort into 
things like true "workflows", we want that effort to be on the business 
layer and outside of Struts.

The need for a true business application controller is burning issue for 
most teams, and perhaps it's time that we addressed it head-on. We've 
been drifting in this direction by moving many of our utilities to the 
Commons, and splitting packages like the Validator in to a Commons 
component and a dependent Struts components. Before we think about 
adding anything like workflow support to the Struts core, perhaps we 
should declare our feelings about whether there should be a business 
layer framework below Struts, and whether any of us are willing to work 
on such a thing.

Or, perhaps it is the case that the server-side of JavaServerFaces will 
be able to fill this role. In which case, the question becomes wheth

RE: Workflow for Struts

[Paul_T_Smith]

Actually I completely agree that business controllers and workflows belong
outside of Struts. I think the problem though lies in the word workflow.
Pageflow is not intended to actually do business work, but to extend the
functionality of the web specific portion of the problem. As a matter of
fact I have actions built to connect pageflow and Struts to WebMethods,
Commons-Workflow, and BEA Weblogic Integration - all completely web agnostic
business controllers. The other thing is not all applications need a full
workflow tool behind struts. Architectural flexibility is what I think we
need. In very complex scenarios a programmer may want to use pageflow and a
workflow engine. In simple scenarios they may want to use just pageflow or
just the workflow. The thing is, pageflow at it's simplist provides
equivalent functionality to the current struts.
Struts needs some elements of these types of functionality to become even
more flexible and provide more ease of use for developers. The thing in
there is significant amount of opportunity for re-use inside the web-tier
alone. For example, navigation/variable handling/errors etc. can present a
significant code challenge in large applications. That's why I created
pageflow, to make struts easier to use for large apps. Recently, I worked on
a large web app with Struts 1.1 using dynamic forms and validator and all of
our business logic was in session beans. This put Struts right in it's sweet
spot and it did very well, the dev team was very pleased. However, we still
had quite a bit of code (14,000 lines) in action classes. 
Here were some of the challenges that pageflow is designed to help with:
- reusable actions - a good deal of the code we wrote was the same. Take a
data object from the business tier, format it for display, take the user
input and pass it to the business tier. The problem was actions aren't
really reusable, you have to factor out common code into utility classes
which doesn't always map well. This is one place were workflow-like (Id
really rather call it pageflow because of the objections you raised) saves
the day.
- contextual pages - if a button (like a save button) was supposed to do
something different in one context over another, we had to do some pretty
convoluted logic in both the actions and the jsp. With pageflow you just use
a separate page-instance and connect it to a separate action. This saves
immense problem around complicated page-action-page combinations.
- variable handling - quite frankly it was difficult to track where form
properties were assigned and how they related to scoped variables. Also, I
had some junior programmers spend significant hours finding bugs in session
memory handling. Pageflow provides a scopes and memory handling that makes
it much easier to track down what is going where.
- flexible events and filters - although not necessary, in our app we wanted
to do some simple filters for a couple of page/action combos, turns out this
is really hard. Also, we had a couple of instances were an event framework
would have simplified our code immensely.

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] 
Sent: Sunday, August 03, 2003 11:58 AM
To: Struts Developers List
Subject: Re: Workflow for Struts

The thing I keep coming back to is whether workflows are a Struts 
problem. I would agree that multipage form *wizards* that collect input 
are definitely a Struts problem. But, I can't but help wonder whether 
more advanced types of workflows would be better defined as part of a 
business application controller -- rather than a presentation front 
controller, like Struts. (Or, presentation service-to-worker controller, 
if you are a J2EE Blueprints follower.)

AFAIK, there really aren't any open-source business application 
controller frameworks "out there" now, and Struts often ends up filling 
this void. Before we talk about extending Struts so that it encroaches 
on business application space, perhaps we should consider whether 
"Struts is enough".

What I'm thinking is that below Struts there should be a pure business 
application controller framework. It would have all the same hallmarks 
as Struts, such as input helpers, locations, handlers, and message 
resources. But, these would all have pure signatures, free of web and 
servlet semantics. Essentially, Struts without HTTP.

While things like "wizards" would live in the Struts layer, things like 
"workflows" would live in this business layer.

Struts could work as an extension of the business framework. Struts 
gathers up the input parameters, and other user gestures, and passes 
them to the business framework. The business framework then passes back 
dispatch tokens (like "success"), messages, and value objects (or 
collections of value objects).

The business application controller decides whether to go to "success", 
"failure", or 

RE: Workflow for Struts

[Paul_T_Smith]

I uploaded the file this morning but didn't change
The release date so the one you have should work. I
Pulled it down also and deployed it manually and it
Worked fine in Tomcat41. I haven't installed it on 4.1.27
So Im downloading it now and trying it out. 

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] 
Sent: Sunday, August 03, 2003 11:51 AM
To: Struts Developers List
Subject: Re: Workflow for Struts

Is the new one part of the Struts SourceForge PageFlow releases? I'm not 
seeing a newer one at this time. I did try downloading and deploying it 
again, and did get the first page to come up, but there are exceptions 
after that.



type Exception report
message
description The server encountered an internal error () that prevented 
it from fulfilling this request.
exception
java.lang.IllegalArgumentException: Step is not part of the current Activity
at 
org.apache.commons.workflow.base.BaseContext.setNextStep(BaseContext.java:79
1)
at 
org.apache.struts.pageflow.PFActionFilter.doFilter(PFActionFilter.java:254)



Just don't know if I have the right version now or not.

-Ted.

[EMAIL PROTECTED] wrote:
> Ted,
> Sorry, I had forgotten to replace the example zip. 
> I have done so now so you shouldn't have a problem,
> though it does take some time to parse the pageflows. 
> I have downloaded it and tried it on Tomcat4.1 and Jboss 3. Paul T Smith
>  
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] 
> Sent: Sunday, August 03, 2003 8:08 AM
> To: Struts Developers List
> Subject: Re: Workflow for Struts
>  
> Paul, I tried to deploy the example
>  
> <http://prdownloads.sourceforge.net/struts/pfexample.zip?download
> <http://prdownloads.sourceforge.net/struts/pfexample.zip?download> >
>  
> under a fresh install of Tomcat 4.1.27 (full boat), but it loops 
> endlessly with these messages:
>  
>  
> DEBUG [HostConfig[localhost]] (Digester.java:1255) -   New 
> match='pageflow/flow/ page-instance/action/steps/step/parameters'
> DEBUG [HostConfig[localhost]] (Digester.java:1279) -   No rules found 
> matching ' pageflow/flow/page-instance/action/steps/step/parameters'.
> DEBUG [HostConfig[localhost]] (Digester.java:942) - characters(
>  )
> DEBUG [HostConfig[localhost]] (Digester.java:1229) - 
> startElement(,param,param)
> DEBUG [HostConfig[localhost]] (Digester.java:1236) -   Pushing body text '
>  '
> DEBUG [HostConfig[localhost]] (Digester.java:1255) -   New 
> match='pageflow/flow/ page-instance/action/steps/step/parameters/param'
> DEBUG [HostConfig[localhost]] (Digester.java:1266) -   Fire begin() for 
> org.apac
> [EMAIL PROTECTED]
> DEBUG [HostConfig[localhost]] (Log.java:44) - adding parameter to step. 
> messageC
> hecking Logon for ${request.username}.
> DEBUG [HostConfig[localhost]] (Log.java:71) - Adding parameter to step 
> org.apac
> he.struts.pageflow.core.LogStep message
> DEBUG [HostConfig[localhost]] (Digester.java:1010) - 
> endElement(,param,param)
> DEBUG [HostConfig[localhost]] (Digester.java:1013) - 
> match='pageflow/flow/page -instance/action/steps/step/parameters/param'
> DEBUG [HostConfig[localhost]] (Digester.java:1014) -   bodyText=''
> DEBUG [HostConfig[localhost]] (Digester.java:1032) -   Fire body() for 
> org.apach
> [EMAIL PROTECTED]
> DEBUG [HostConfig[localhost]] (Digester.java:1052) -   Popping body text '
>  '
> DEBUG [HostConfig[localhost]] (Digester.java:1062) -   Fire end() for 
> org.apache
> [EMAIL PROTECTED]
> DEBUG [HostConfig[localhost]] (Digester.java:942) - characters(
>  )
> DEBUG [HostConfig[localhost]] (Digester.java:1229) - 
> startElement(,param,param)
> DEBUG [HostConfig[localhost]] (Digester.java:1236) -   Pushing body text '
>  
>  '
>  
>  
>  
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>  
>  
>  
>  
> Paul T Smith
>  
> 


-- 
Ted Husted,
   Junit in Action  - <http://www.manning.com/massol/>,
   Struts in Action - <http://husted.com/struts/book.html>,
   JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.



-
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]

Re: Workflow for Struts

[Joe Germuska]

At 12:58 -0400 8/3/03, Ted Husted wrote:
AFAIK, there really aren't any open-source business application 
controller frameworks "out there" now, and Struts often ends up 
filling this void. Before we talk about extending Struts so that it 
encroaches on business application space, perhaps we should consider 
whether "Struts is enough".

What I'm thinking is that below Struts there should be a pure 
business application controller framework. It would have all the 
same hallmarks as Struts, such as input helpers, locations, 
handlers, and message resources. But, these would all have pure 
signatures, free of web and servlet semantics. Essentially, Struts 
without HTTP.
Have you (or anyone on the list) looked at Bob McWhirter's 
"werkflow"? http://werkflow.codehaus.org/

I've been meaning to look at it more closely to see if it qualifies 
as some or part of the "open-source business application controller 
frameworks" you mention.

Joe
--
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Workflow for Struts

[Ted Husted]

The thing I keep coming back to is whether workflows are a Struts 
problem. I would agree that multipage form *wizards* that collect input 
are definitely a Struts problem. But, I can't but help wonder whether 
more advanced types of workflows would be better defined as part of a 
business application controller -- rather than a presentation front 
controller, like Struts. (Or, presentation service-to-worker controller, 
if you are a J2EE Blueprints follower.)

AFAIK, there really aren't any open-source business application 
controller frameworks "out there" now, and Struts often ends up filling 
this void. Before we talk about extending Struts so that it encroaches 
on business application space, perhaps we should consider whether 
"Struts is enough".

What I'm thinking is that below Struts there should be a pure business 
application controller framework. It would have all the same hallmarks 
as Struts, such as input helpers, locations, handlers, and message 
resources. But, these would all have pure signatures, free of web and 
servlet semantics. Essentially, Struts without HTTP.

While things like "wizards" would live in the Struts layer, things like 
"workflows" would live in this business layer.

Struts could work as an extension of the business framework. Struts 
gathers up the input parameters, and other user gestures, and passes 
them to the business framework. The business framework then passes back 
dispatch tokens (like "success"), messages, and value objects (or 
collections of value objects).

The business application controller decides whether to go to "success", 
"failure", or "outForBeer". Struts fills in the path to the web 
application resource representing each token. Likewise, the business 
application controller passed back keys to the message resources, and 
Struts renders the localized versions. And, of course, the business 
application controller passes back objects with dynamic data to display, 
and Struts sends them to the server pages that can render them.

This is exactly what many (or even most) of us are doing now, except 
that we are all rolling our own proprietary solutions. I've worked with 
some companies that have already designed full-blown business layer 
frameworks such as this, based on the Struts architecture.

It may be time to take the hint and develop an open source business 
application controller framework where we can "share the wealth" as we 
have done with struts. Essentially, the idea would be to take Struts and 
abstract-out the web and servlet semantics. Where Struts might use an 
Action with an

  ActionForward 
execute(ActionMapping,ActionForm,SerlvetRequest,ServletResponse),

the business layer framework would use a Handler with a

  Location process(Dispatcher,Helper,Context)

Struts then becomes a HTTP/Servlet extension of the business application 
controller framework. Where many developers are now writing "Actions", 
they could write web-semantic-free "Handlers" instead. Action classes 
would still be available when you really need to use web semantics, but 
otherwise, development effort can be put into web-free Handler classes. 
When web-semantics are not required, a single "gateway" Action can 
provide an adapter between Struts and the business layer framework. This 
moves most of the hard-core development completely out of Action classes 
and into platform-independant "POJO" classes.

I think the overall Struts architecture works great for a lot of people 
(including me!). But when it comes to putting development effort into 
things like true "workflows", we want that effort to be on the business 
layer and outside of Struts.

The need for a true business application controller is burning issue for 
most teams, and perhaps it's time that we addressed it head-on. We've 
been drifting in this direction by moving many of our utilities to the 
Commons, and splitting packages like the Validator in to a Commons 
component and a dependent Struts components. Before we think about 
adding anything like workflow support to the Struts core, perhaps we 
should declare our feelings about whether there should be a business 
layer framework below Struts, and whether any of us are willing to work 
on such a thing.

Or, perhaps it is the case that the server-side of JavaServerFaces will 
be able to fill this role. In which case, the question becomes whether 
an approach to workflows will complement JSF or not.

Though, personally, I would be most interested in a business application 
controller framework that was platform-independant and could be 
implemented on Java or C#, or even PHP.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Workflow for Struts

[Ted Husted]

Is the new one part of the Struts SourceForge PageFlow releases? I'm not 
seeing a newer one at this time. I did try downloading and deploying it 
again, and did get the first page to come up, but there are exceptions 
after that.



type Exception report
message
description The server encountered an internal error () that prevented 
it from fulfilling this request.
exception
java.lang.IllegalArgumentException: Step is not part of the current Activity
	at 
org.apache.commons.workflow.base.BaseContext.setNextStep(BaseContext.java:791)
	at 
org.apache.struts.pageflow.PFActionFilter.doFilter(PFActionFilter.java:254)



Just don't know if I have the right version now or not.

-Ted.

[EMAIL PROTECTED] wrote:
Ted,
Sorry, I had forgotten to replace the example zip. 
I have done so now so you shouldn't have a problem,
though it does take some time to parse the pageflows. 
I have downloaded it and tried it on Tomcat4.1 and Jboss 3. Paul T Smith
 
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] 
Sent: Sunday, August 03, 2003 8:08 AM
To: Struts Developers List
Subject: Re: Workflow for Struts
 
Paul, I tried to deploy the example
 
<http://prdownloads.sourceforge.net/struts/pfexample.zip?download
<http://prdownloads.sourceforge.net/struts/pfexample.zip?download> >
 
under a fresh install of Tomcat 4.1.27 (full boat), but it loops 
endlessly with these messages:
 
 
DEBUG [HostConfig[localhost]] (Digester.java:1255) -   New 
match='pageflow/flow/ page-instance/action/steps/step/parameters'
DEBUG [HostConfig[localhost]] (Digester.java:1279) -   No rules found 
matching ' pageflow/flow/page-instance/action/steps/step/parameters'.
DEBUG [HostConfig[localhost]] (Digester.java:942) - characters(
 )
DEBUG [HostConfig[localhost]] (Digester.java:1229) - 
startElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1236) -   Pushing body text '
 '
DEBUG [HostConfig[localhost]] (Digester.java:1255) -   New 
match='pageflow/flow/ page-instance/action/steps/step/parameters/param'
DEBUG [HostConfig[localhost]] (Digester.java:1266) -   Fire begin() for 
org.apac
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Log.java:44) - adding parameter to step. 
messageC
hecking Logon for ${request.username}.
DEBUG [HostConfig[localhost]] (Log.java:71) - Adding parameter to step 
org.apac
he.struts.pageflow.core.LogStep message
DEBUG [HostConfig[localhost]] (Digester.java:1010) - 
endElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1013) - 
match='pageflow/flow/page -instance/action/steps/step/parameters/param'
DEBUG [HostConfig[localhost]] (Digester.java:1014) -   bodyText=''
DEBUG [HostConfig[localhost]] (Digester.java:1032) -   Fire body() for 
org.apach
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Digester.java:1052) -   Popping body text '
 '
DEBUG [HostConfig[localhost]] (Digester.java:1062) -   Fire end() for 
org.apache
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Digester.java:942) - characters(
 )
DEBUG [HostConfig[localhost]] (Digester.java:1229) - 
startElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1236) -   Pushing body text '
 
 '
 
 
 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
Paul T Smith
 



--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Workflow for Struts

[Paul_T_Smith]

Ted,
Sorry, I had forgotten to replace the example zip. 
I have done so now so you shouldn't have a problem,
though it does take some time to parse the pageflows. 
I have downloaded it and tried it on Tomcat4.1 and Jboss 3. Paul T Smith
 
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] 
Sent: Sunday, August 03, 2003 8:08 AM
To: Struts Developers List
Subject: Re: Workflow for Struts
 
Paul, I tried to deploy the example
 
<http://prdownloads.sourceforge.net/struts/pfexample.zip?download
<http://prdownloads.sourceforge.net/struts/pfexample.zip?download> >
 
under a fresh install of Tomcat 4.1.27 (full boat), but it loops 
endlessly with these messages:
 
 
DEBUG [HostConfig[localhost]] (Digester.java:1255) -   New 
match='pageflow/flow/ page-instance/action/steps/step/parameters'
DEBUG [HostConfig[localhost]] (Digester.java:1279) -   No rules found 
matching ' pageflow/flow/page-instance/action/steps/step/parameters'.
DEBUG [HostConfig[localhost]] (Digester.java:942) - characters(
 )
DEBUG [HostConfig[localhost]] (Digester.java:1229) - 
startElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1236) -   Pushing body text '
 '
DEBUG [HostConfig[localhost]] (Digester.java:1255) -   New 
match='pageflow/flow/ page-instance/action/steps/step/parameters/param'
DEBUG [HostConfig[localhost]] (Digester.java:1266) -   Fire begin() for 
org.apac
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Log.java:44) - adding parameter to step. 
messageC
hecking Logon for ${request.username}.
DEBUG [HostConfig[localhost]] (Log.java:71) - Adding parameter to step 
org.apac
he.struts.pageflow.core.LogStep message
DEBUG [HostConfig[localhost]] (Digester.java:1010) - 
endElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1013) - 
match='pageflow/flow/page -instance/action/steps/step/parameters/param'
DEBUG [HostConfig[localhost]] (Digester.java:1014) -   bodyText=''
DEBUG [HostConfig[localhost]] (Digester.java:1032) -   Fire body() for 
org.apach
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Digester.java:1052) -   Popping body text '
 '
DEBUG [HostConfig[localhost]] (Digester.java:1062) -   Fire end() for 
org.apache
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Digester.java:942) - characters(
 )
DEBUG [HostConfig[localhost]] (Digester.java:1229) - 
startElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1236) -   Pushing body text '
 
 '
 
 
 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
Paul T Smith
 

RE: Workflow for Struts

[Paul_T_Smith]

Ted,
Sorry, I had forgotten to replace the example zip. 
I have done so now so you shouldn't have a problem,
though it does take some time to parse the pageflows. 
I have downloaded it and tried it on Tomcat4.1 and Jboss 3.
Paul T Smith

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] 
Sent: Sunday, August 03, 2003 8:08 AM
To: Struts Developers List
Subject: Re: Workflow for Struts

Paul, I tried to deploy the example

<http://prdownloads.sourceforge.net/struts/pfexample.zip?download>

under a fresh install of Tomcat 4.1.27 (full boat), but it loops 
endlessly with these messages:


DEBUG [HostConfig[localhost]] (Digester.java:1255) -   New 
match='pageflow/flow/
page-instance/action/steps/step/parameters'
DEBUG [HostConfig[localhost]] (Digester.java:1279) -   No rules found 
matching '
pageflow/flow/page-instance/action/steps/step/parameters'.
DEBUG [HostConfig[localhost]] (Digester.java:942) - characters(
 )
DEBUG [HostConfig[localhost]] (Digester.java:1229) - 
startElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1236) -   Pushing body text '
 '
DEBUG [HostConfig[localhost]] (Digester.java:1255) -   New 
match='pageflow/flow/
page-instance/action/steps/step/parameters/param'
DEBUG [HostConfig[localhost]] (Digester.java:1266) -   Fire begin() for 
org.apac
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Log.java:44) - adding parameter to step. 
messageC
hecking Logon for ${request.username}.
DEBUG [HostConfig[localhost]] (Log.java:71) - Adding parameter to step 
org.apac
he.struts.pageflow.core.LogStep message
DEBUG [HostConfig[localhost]] (Digester.java:1010) - 
endElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1013) - 
match='pageflow/flow/page
-instance/action/steps/step/parameters/param'
DEBUG [HostConfig[localhost]] (Digester.java:1014) -   bodyText=''
DEBUG [HostConfig[localhost]] (Digester.java:1032) -   Fire body() for 
org.apach
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Digester.java:1052) -   Popping body text '
 '
DEBUG [HostConfig[localhost]] (Digester.java:1062) -   Fire end() for 
org.apache
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Digester.java:942) - characters(
 )
DEBUG [HostConfig[localhost]] (Digester.java:1229) - 
startElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1236) -   Pushing body text '

 '



-
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]

Re: Workflow for Struts

[Ted Husted]

Paul, I tried to deploy the example



under a fresh install of Tomcat 4.1.27 (full boat), but it loops 
endlessly with these messages:

DEBUG [HostConfig[localhost]] (Digester.java:1255) -   New 
match='pageflow/flow/
page-instance/action/steps/step/parameters'
DEBUG [HostConfig[localhost]] (Digester.java:1279) -   No rules found 
matching '
pageflow/flow/page-instance/action/steps/step/parameters'.
DEBUG [HostConfig[localhost]] (Digester.java:942) - characters(
)
DEBUG [HostConfig[localhost]] (Digester.java:1229) - 
startElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1236) -   Pushing body text '
'
DEBUG [HostConfig[localhost]] (Digester.java:1255) -   New 
match='pageflow/flow/
page-instance/action/steps/step/parameters/param'
DEBUG [HostConfig[localhost]] (Digester.java:1266) -   Fire begin() for 
org.apac
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Log.java:44) - adding parameter to step. 
messageC
hecking Logon for ${request.username}.
DEBUG [HostConfig[localhost]] (Log.java:71) - Adding parameter to step 
org.apac
he.struts.pageflow.core.LogStep message
DEBUG [HostConfig[localhost]] (Digester.java:1010) - 
endElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1013) - 
match='pageflow/flow/page
-instance/action/steps/step/parameters/param'
DEBUG [HostConfig[localhost]] (Digester.java:1014) -   bodyText=''
DEBUG [HostConfig[localhost]] (Digester.java:1032) -   Fire body() for 
org.apach
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Digester.java:1052) -   Popping body text '
'
DEBUG [HostConfig[localhost]] (Digester.java:1062) -   Fire end() for 
org.apache
[EMAIL PROTECTED]
DEBUG [HostConfig[localhost]] (Digester.java:942) - characters(
)
DEBUG [HostConfig[localhost]] (Digester.java:1229) - 
startElement(,param,param)
DEBUG [HostConfig[localhost]] (Digester.java:1236) -   Pushing body text '

'



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Workflow for Struts

[Paul_T_Smith]

Dear Struts Dev,
I have launched a sub-project at the struts sourceforge site which provides
workflow functionality for struts. Essentially it is a re-write of the
struts controller and provides a significant set of additional features. I
am currently working on finalizing the struts example and writing
documentation, but the basic framework is there. 
PAGEFLOW EXAMPLE
 
Heres what a page looks like...





... page declaration

 
Heres what a page flow looks like...






















 
PAGEFLOW FUNCTIONALITY
 
1. Contextual Pages: Re-use of pages across PageFlows. 
 
2. Re-usable Actions: Actions can be declared at the application or pageflow
level
and reused inside of the workflow. 
 
3. Variable Handling: You can do almost all of your web variable handling in
the xml
file instead of in code (saves loads of time!) Additionally pageflow
provides a new web scope
which is automatically cleaned up for the developer. 
 
4. Event Handling: 
- Entering, exiting, or wrapping a pageflow.
- Entering, exiting an action.
- Entering, exiting a page instance.
- Adding, removing from a scope.
- Setting values on a form, validating a form.
- Sending HTML to the client.
- An error occurs.
 
5. Re-Usable Steps: I get really tired of writing the same code over and
over again.
That is why I love workflow tools (webmethods, BEA BPM, etc.). Workflow
tools offer
me a meta programming language with which I can create re-usable steps and
just 
pass in different parameters. 
 
pageflow provides exactly the same functionality (uses the commons-workflow
library). If your application uses session
beans out of an EJB container, just use the InitialContext and
CallSessionBean steps.
Sometimes of course this wont work, either because of the complexity of the
logic
involved or your specific project context. In that case just put your custom
code
into a step and put that step into the action. 
 
6. Nested PageFlows: This is really cool! pageflow allows you to nest other
PageFlows
inside of each other. You can pass variables from one to the other.
If managed and thought through properly this could be a very powerful
feature. 
 
7. Fine-Grained Filters: I honestly dont know if anyone wants this, but it's
always
annoyed me that I could only use filters at the top web application level.
What if 
you want to convert your application to use a new filter incrementally? What
if your
filter isnt needed everywhere? Currently you would have to code the
contextual logic 
directly in your filter.pageflow allows you to put your filter at the
application, 
pageflow, page-instance and action levels.
 
8. Fine-Grained Error Handling: Another gripe I have is trying to figure out
flexible
error handling in my applications.You may use or declare error handlers at
- application layer
- pageflow layer
- action layer
 
9. Fine-Grained Form Control: I had two big beefs with Struts 1.1 forms.
Figuring out when and where forms are initialized and mapping the data
to/from my value objects. In pageflow,
each page declaration is connected with a form. The form
properties have two new elements, mapTo and mapFrom. These elemements simply
connect
the form property to two variables, one to get the value from
(session.user.name) 
and one to put the changed value into (request.changeduser.name).
 
The framework is in no way complete, but it is to the point where people can
start commenting on it. Let me know what you think.
 
Paul T Smith