With the enclosed XML things become much clearer. I have some comments:
* Some <app:forward ...> tags do not have a closing tag. I believe it
should close after the <app:navigate> part (or after the core:if and
core:goto parts).
* The <app:branch control="..." idref="..."> is also not clear where
the control comes from. It should be enclosed by an <core:if> when
the branch is conditional.
* IMO the $parameter should be adressed by a dot instead of a colon:
<ctx:set name="username" value="$parameter.username"/>
this is more java and bean like!
Wouldn't the following structure better represent the workflow?
<flow:task> instead of the <flow:workflow>
<flow:step view="..."> instead of the <app:navigate> which is rendered
by a specific view (instead of the <app:forward>).
<ctx:set ...>
<core:if ...> replacing the <app:branch>. The enclosing
<flow:branch> <app:navigate> is not necessary. The branch may
</core:if> be enclosed within <core:if> and preceeded by
<ctx:set> cascades...
Will the workflow manager keep the task/step state to continue
the navigation? Or will the application supply the parameters
of the desired task/step IDs (e.g. within the URI)?
In a previous project (early 2000) I faced a similar requirement
and created a similar specification. I watched closely the cocoon2
and turbine approaches of web applications, but found these not
appropiate. JSP could have solved the view part, but would have been
ugly.
I finally created the application based on Velocity, where I
scripted exacly this workflow task handling per-request using VTL.
This then loaded a corresponding step controller VTL script that
did the <ctx:set>, <core:if> and <core:invoke> parts (using the VTL
conterparts) and then loaded the view template. My application
then used a skin layout to format the final output (à la Turbine).
The used context tools used are already part of commons.ruppert in
the sandbox. The controller in my application can read external files
(directories, text and xml) and can run external scripts with these
tools. Velocity and a simple ApplicationServlet is all that's
neccesary for this to run. This is working great and is *really*
simple!
By mapping the VTL controller code to XML it might gain some
toolability (structure & syntax checks plus automatic generation
and information extraction).
I have concrete examples for such an application approach. I can
supply sample XMLs for further discussions/clarifications.
Please contact me for any questions.
:) Christoph
Ted Husted wrote:
>
> 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/
