Re: Upcoming Workflow Proposal

[Ted Husted <hu...@apache.org>]

Craig R. McClanahan wrote:

> It should be feasible to subdivide the "Struts integration" 
> into generic integration with the web layer (mapping to 
> servlet API concepts) and the features that are truly 
> Struts-specific (such as mapping a logical ActionForward 
> to a particular resource path)."

Maybe we should do that sooner than later, and start out talking about
"framework integration" instead. 

The pseudo-code for the original proposal contemplates three tiers:
core, web, and "struts". The elements labeled "struts" are not actually
part of the current framework. Perhaps it would be helpful to label
these "app" instead, with the understanding that this is the tier that
each framework would implement for its own application. 

While Struts does use terms like "forward" and "action", these are
common terms that stem from HTTP and HTML. If a framework did not
support named, or logical forwards, it might have to use a URI instead. 

Meanwhile, the "web" tier might also be generalized as the context tier,
and there may be implementations of this for Web, J2EE/EJB, et cetera.
The workflow script might not need to know which implementation was
being used, and so we could just refer to the context instead.

To wit, 

<flow:workflow name="Application Logon">

<-- Display the logon form (Struts maps to a real JSP page) -->
<app:forward id="display" name="Logon Page"/>

<-- Authenticate the username and password, returning a Principal
		if accepted, or null if not -->
<ctx:set name="username" value="$parameter:username"/>
<ctx:set name="password" value="$parameter:password"/>
<core:invoke bean="authenticator" method="authenticate">
	<core:param type="java.lang.String" value="$username"/>
	<core:param type="java.lang.String" value="$password"/>
	<core:return name="principal"/>
<core:invoke/>

<-- If no Principal was returned, branch back to the logon form -->
<core:if expr="$principal == null">
	<ctx:set name="error" value="$messages.lookup('invalid.logon')"/>
	<core:branch idref="display"/>
</core:if>

<-- Exit to the "Main Menu" workflow -->
<core:goto name="Main Menu"/>

</flow:workflow>


<flow:workflow name="Simple Wizard Application">

<!-- Display the first page of the interation -->
<app:forward id="page1" name="Simple Wizard Page 1">

<!-- Process navigation input from the first page -->
<app:navigate>
	<app:branch control="CANCEL" idref="cancel"/>
	<app:branch control="FINISH" idref="finish"/>
	<app:branch control="NEXT"   idref="page2"/>
</app:navigate>

<!-- Display the second page of the interation -->
<app:forward id="page2" name="Simple Wizard Page 2">

<!-- Process navigation input from the second page -->
<app:navigate>
	<app:branch control="CANCEL" idref="cancel"/>
	<app:branch control="FINISH" idref="finish"/>
	<app:branch control="NEXT"   idref="page3"/>
	<app:branch control="PREV"   idref="page1"/>
</app:navigate>

<!-- Display the third page of the interation -->
<app:forward id="page3" name="Simple Wizard Page 3">

<!-- Process navigation input from the third page -->
<app:navigate>
	<app:branch control="CANCEL" idref="cancel"/>
	<app:branch control="FINISH" idref="finish"/>
	<app:branch control="PREV"   idref="page2"/>
</app:navigate>

<!-- Process the FINISH navigation control as appropriate -->
<xxx:yyy id="finish" .../>
<core:goto name="Main Menu"/>

<!-- Process the CANCEL navigation control as appropriate -->
<xxx:yyy id="cancel" .../>
<core:goto name="Main Menu"/>

</flow:workflow>

So there would be "app" and "ctx" APIs, or interfaces, in the Commons,
and there could be default implementations of a Web, J2EE, and whatever
context. But no working implementation of the "app" API. It would be up
to developers working with Turbine, Struts, Barracuda, or whatever to
implement the "app" API for a given framework. But the code implementing
the "ctx" and "core" elements would be shared. We might even want to
make "core" a general API too, and then offer a Java implementation of
that, just to keep our options open.

Properly done, it could mean that the workflow scripts for some
frameworks could be shared. Though, I imagine there may eventually be
framework-specific elements too.

I'd also suggest that the custom tags, which would apparently be part of
the "app" layer, be part of the Commons distribution, so that another
JSP framework does not have to reimplement these.  Whatever resources
that are needed can be exposed in the ServletContext under known names.

Since there does seem to be interest in doing this as a Commons project
(it has my +1 and I even may still be a Committer here and everything
;-), we might keep the initial discussion in the Commons, and refactor
the Struts proposal as a Commons proposal, using neutral language. 

(I could help with that part of it today ...)


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/about/struts/