OSW: doAction, codebase, features and Roadmap

Hi,

    While automating the permission checking inside the conditions, putting
a ACL into the Inputs, the code didn't work. That was because the doAction
checks for  all the availableActions without the Inputs. As we posted
this issue before and it is not clear if this the desired behavior, we
tried to overload the doAction, so the Inputs in the parameter are supplied
as parameter to our isAvaliableAction method, instead of passing null to
get ALL the available actions.

    But the doAction is a facade for the 200+ lines of code method
transitionWorkflow, wihich invokes createNewCurrentStep, and so on. So
overloading the doAction method, means copying a lot of the AbstractWorkflow
to the subclass because the methods are private.

    I think the codebase is really needing a refactoring, in order to make
it more object oriented and efficient. Why using objects internally to later
convert to primitives as return, to get primitives a parametes and convert
them to objects in order to do the work? Why the ActionDescriptor is not
aware of the Step? This forces to check all the StepDescriptors, to look
where the Action is defined. And this kind of things makes the code to
behave like the doAction, where the Action is known but ALL the actions
are checked for availability...

    But the efforts to make changes and improve must be drived by the
features, and I haven't found a Road Map for OSWorkflow. Asking the users of
the workflow for features to be introduced in version 2.5, when this release
is supposed to be released "soon", wont drive the project in a ordered
way.

    I've seen a great effort running the implementation of features (nice
features actually), but I am concerned with the lack of effort to get a
consolidated codebase.

    Does Pat and Hani need more "formal" help? How can users become
active developers, commiters, documenters? Maybe a growing
community of developers / commiters is needed, and more formal
patterns to the applied.

    The benefits of a Road Map? Pat and Hani would be tackled with less
feature requirements, and the we (the users) would know when to shout up our
requirements, and where our support (patches, bug reports or documentation)
will be more usefull. Successfull OpenSource projects benefit from the
effort of the developers and users community toward a clear goal, hacking
the
code in our sandboxes to fit out special needs would be a waste of time and
resources.

    Thanks for your time, and thanks to Pat and Hani for this big effort
known as OSWorkflow.

Aníbal



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge