On Mon, 13 Aug 2001, Jon Stevens wrote:
> First off, this is a kick ass first start. Very nice work Craig.
>
> Comments:
>
> Activity.java:
>
> Add more methods
> Step[] getSteps()
> void setSteps(Step[] steps)
>
OK. The internal stuff should be as agnostic as possible about who
initialization happens, so this makes sense.
> Context.java:
>
> Context is being used as a name for way to many things to make it this
> generic. I think this should be renamed to something like
> "StateContext.java"
>
Maybe just "State"? This thing is definitely different from a Context in
Velocity.
The really important issue is that this thing is dynamic and maintained
(in essence) per-user-interation, while Activity and Step are static and
shared if more than one user is executing the same activity at the same
time.
> I could be wrong here because I don't see the entire picture yet, but I
> think that Scope should be managed outside of the Context. Take this
> technique from Turbine/Velocity of being able to nest Contexts and
> provide scope through referencing nested Contexts.
>
The view in the current code is that scopes are "side by side" rather than
nested, and can be accessed (from a Step) via a name. A particular
instance of Context can have a number of Scope implementations plugged in,
totally independent of the execution engine.
For a web layer integration using JSP, it's pretty natural to have a scope
for request attributes, session attributes, and context attributes.
However, it's still perfectly feasible to add additional scopes (or
replace one of these -- for Turbine/Velocity, it might be more natural to
have one instead of three because that's more similar to your existing
programming model.
Note that you can have your cake and eat it too -- when I defined the
literal index values in WebContext, so you can stick your own Scope in
anywhere in the search order you like.
> Step.java:
>
> Next/Previous. What happens if there isn't one? Only execute throws a
> StepException. Also, I would prefer a more JavaBean syntax than
> "execute". I believe "do" is the right keyword...ie: "doExecute()". Can
> someone point me to the java.sun.com documentation on the method naming
> conventions for Beans?
>
When the calculated nextStep value (in the Context implementation) is
null, that is a signal that the current Activity has been completed. It
can happen in one of three ways:
* You just executed the last Step in this Activity (the linked
list processing does this automatically).
* Your Step calls context.setNextStep(null) before it returns,
because it has algorithmically decided that the Activity is finished.
* You executed the <core:exit> tag, which does the above.
The standard logic for this is in
org.apache.commons.workflow.base.BaseContext, in the execute() method.
For JavaBeans naming patterns, the best info source is the JavaBeans 1.0.1
specification:
http://java.sun.com/products/javabeans/docs/spec.html
It has naming patterns for events, event listeners, and property
getters/setters, but I didn't find any for "action" type
methods. Throughout this initial set of code I was pretty much into
one-word names where it was possible :-).
> More comments to follow as I look into things further.
>
> -jon
>
>
Craig
