You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2003/06/03 12:41:31 UTC
Workflow definition document
Hi Lenya developers,
could you please discuss the following draft of a workflow
definition document:
--------------------
a) general + fexible
--------------------
<workflow xmlns="http://apache.org/cocoon/lenya/workflow/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://apache.org/cocoon/lenya/workflow/1.0
../../../resources/entities/workflow/workflow.xsd">
<!-- ====================================================
Declaration of action and condition types
As the workflow model basically allows different kinds
of actions and conditions, I we could allow the
declaration of types.
==================================================== -->
<condition-type name="role"
class="org.apache.lenya.cms.workflow.RoleCondition"/>
<condition-type name="variable"
class="org.apache.lenya.workflow.impl.VariableCondition"/>
<action-type name="cms"
class="org.apache.lenya.cms.workflow.CMSAction"/>
<action-type name="assign"
class="org.apache.lenya.workflow
.impl.BooleanVariableAssignmentImpl"/>
<state id="redaktion" initial="true"/>
<state id="review"/>
<state id="live"/>
<!-- ====================================================
Variable declarations
The model only allows boolean variables, so it makes no
sense to declare variable types.
==================================================== -->
<variable name="is-live" value="false"/>
<!-- ====================================================
Transitions
Event: A transition is triggered by exactly one event with no
further options, therefore it is expressed as an attribute.
Conditions: Multiple conditions are allowed, they can be
configured. I suggest to use condition elements with
nested configuration (usually an expression).
Assignments: In this example, assignments are expressed as
a certain type of action.
==================================================== -->
<transition event="publish" source="redaktion" destination="review">
<condition type="role">editor</condition>
</transition>
<transition event="approve"
source="review" destination="live">
<condition type="role">manager</condition>
<action type="assign">is-live = true</action>
<action type="cms">publish</action>
</transition>
<transition event="disapprove"
source="review" destination="redaktion">
<condition type="role">manager</condition>
</transition>
<transition event="edit"
source="live" destination="redaktion">
<condition type="role">editor</condition>
<action type="cms">save</action>
</transition>
<transition event="edit"
source="redaktion" destination="redaktion">
<condition type="role">editor</condition>
<action type="cms">save</action>
</transition>
<transition event="deactivate"
source="redaktion" destination="redaktion">
<condition type="variable">is-live = true</condition>
<action type="assign">is-live = false</action>
<action type="task">delete-live-document</action>
</transition>
</workflow>
-------------------------
b) simple + less flexible
-------------------------
<workflow xmlns="http://apache.org/cocoon/lenya/workflow/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://apache.org/cocoon/lenya/workflow/1.0
../../../resources/entities/workflow/workflow.xsd">
<state id="redaktion" initial="true"/>
<state id="review"/>
<state id="live"/>
<variable name="is-live" value="false"/>
<!-- ====================================================
Transitions
Event: A transition is triggered by exactly one event with no
further options, therefore it is expressed as an attribute.
Conditions: Every condition type (variable / role) is expressed
by a certain predefined element or attribute.
Assignments: Special elements for assignments.
==================================================== -->
<transition event="publish" source="redaktion" destination="review">
<condition type="role" value="editor"/>
</transition>
<transition event="approve"
source="review" destination="live">
<role>manager</role>
<assign variable="is-live" value="true"/>
<action>publish</action>
</transition>
<transition event="disapprove"
source="review" destination="redaktion">
<role>manager</role>
</transition>
<transition event="edit"
source="live" destination="redaktion">
<role>editor</role>
<action>save</action>
</transition>
<transition event="edit"
source="redaktion" destination="redaktion">
<role>editor</role>
<action>save</action>
</transition>
<transition event="deactivate"
source="redaktion" destination="redaktion">
<check variable="is-live" value="true"/>
<assign variable="is-live" value="false"/>
<action>delete-live-document</action>
</transition>
</workflow>
What do you think?
Thanks,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Workflow definition document
Posted by Andreas Kuckartz <A....@ping.de>.
> > Are there any suggestions how these files can be created and edited by
> > administrators without dealing with XML?
>
> At the moment, this has a low priority. IMHO we shouldn't
> invest much energy in implementing such rarely used features,
> we should concentrate on more important things ...
I agree. I was thinking about suggestions of already existing software.
Unfortunately demonstrating GUIs for rarely used features can be important
to convince certain people.
Here is one project which is using WfMC specifications:
http://debian-sf.objectweb.org/projects/jawe/
http://www.objectweb.org/architecture/meetings/archi-03-01/jawe.pdf
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Workflow definition document
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Kuckartz wrote:
> The first alternative looks good.
>
> Are there any suggestions how these files can be created and edited by
> administrators without dealing with XML?
At the moment, this has a low priority. IMHO we shouldn't
invest much energy in implementing such rarely used features,
we should concentrate on more important things ...
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Workflow definition document
Posted by Andreas Kuckartz <A....@ping.de>.
The first alternative looks good.
Are there any suggestions how these files can be created and edited by
administrators without dealing with XML?
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Workflow definition document
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Hi Andreas
Andreas Hartmann wrote:
> Hi Daniel,
>
> Daniel Fagerstrom wrote:
...
> Yes, there are some things that are not yet ready. E.g., I'm not sure
> how to implement the persistence of state variables, probably the
> current values will be stored in the history file.
Seem like a good starting point, one could possibly refer to the history
file through a modifiable source, and thus make it possible to store the
data in other forms than as a file.
>
>>> At least the latter one would be very interesting. I already thought
>>> about "Avalonizing" :) the engine.
>>
>>
>> I would be interested in taking part of that process and has earlier
>> experience in building Avalon based frameworks. I will be traveling
>> for the next two weeks, but after that I could spend some time on it.
>
>
> This would be great. We need someone with Avalon experience.
>
> BTW - are you experienced with the logging framework?
I used it in my own framework, but I just reused log handling code from
the examples in the Avalon documentation so I have no in depth knowledge.
> We're
> looking for an alternative to log4j. Is logkit the way to go
> or rather the Avalon framework logger?
I don't know the details but I would propose to do as in Cocoon as long
as it makes sense. In Cocoon, most components extends AbstractLogEnabled
and get logger from that class, I think one could use most loggers, but
that Cocoon uses Logkit.
>
>> There are some style similarities to the sitemap in logkit.xconf and
>> and instrumentation.xconf and to somewhat lesser degree in
>> cocoon.xconf. But I don't recall any discussions about it on
>> Cocoon-dev. Stefano sometimes refer to long discussions about sitemap
>> design when Cocoon2 was created, I have no specific references.
>
>
> OK, I'll take a look at these files and try to extract the
> best-practise patterns.
Good.
...
>> In a later stage I think it would be a good idea to be able to
>> controll the WF engine from flowscripts as well, as flowscripts more
>> and more are becomming the prefered way to handle side effects within
>> the Cocoon comunity (this is of course not an uncontroversial
>> statment ;) ).
>
>
> Are you familiar with flowscript?
I have not started to use it in any projects yet, but that will
hopefully change very soon. But I have followed it (and in the beginning
critizized it), from its very beginning.
> In the mailing list I read that
> there's a lack of documentation, I didn't have the time to take a
> look at it by now.
The documentation is growing all the time, there are documentation in
the Cocoon wiki, and Christopher Olivier checked in a lot of
documentation recently, he (and others) have also written some demo
applications in flowscripts that you can find in the scratchpad.
Stefano hates actions and is very entusiastic about flowscripts and more
and more people at cocoon-dev seem to share his opinion. I would at
least guess that flowscripts will be _the_ way to handle side effects in
Cocoon and that actions only will be kept for back compatibility. But
there are of course other opinions about this.
>
>
>> There is also a need for using and presenting the state of an WF
>> instance from the sitemap.
>
>
> This is very easy to achieve. For instance, the WorkflowMenuTransformer
> inserts a tag with the current workflow state ID into the menu
> (so the state is displayed in the Lenya menubar).
>
>> I saw that you have started a thread about the format of the WF
>> instance. Are you planning to make the WF instance description
>> available from a generator or what is your idea?
>
>
> Not directly. You can create a WorkflowDocument (a CMS document wrapper
> that is a WF instance) using the WorkflowFactory.
Ok
/Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Workflow definition document
Posted by Andreas Hartmann <an...@apache.org>.
Hi Daniel,
Daniel Fagerstrom wrote:
> Hi Andreas
>
> Andreas Hartmann wrote:
>
>> but I might be interested in integrating
>> an existing engine if this makes Lenya more stable or standards
>> compliant.
>
> Even if I'm in general is very much for standard compliance, I have not
> been that entusiastic about the WF standards I have seen this far. At
> this stage I think that it is better to do something rather minimal.
Yes, my impression was similar.
>> If you really think that the API can be used for other purposes,
>> feel free to use it! But I'm afraid the current community won't
>> invest much work in making it more flexible than we need for Lenya.
>> Of course, if you want to do so - that would be great!
>> The more applications there will be, the more consolidated
>> code will develop (at least I hope so ...)
>
> For the moment I would be happy with Lenyas WF engine, but as always,
> the devil is in the details ;) there might been things that I have
> missed, we will see.
Yes, there are some things that are not yet ready. E.g., I'm not sure
how to implement the persistence of state variables, probably the
current values will be stored in the history file.
>> At least the latter one would be very interesting. I already thought
>> about "Avalonizing" :) the engine.
>
> I would be interested in taking part of that process and has earlier
> experience in building Avalon based frameworks. I will be traveling for
> the next two weeks, but after that I could spend some time on it.
This would be great. We need someone with Avalon experience.
BTW - are you experienced with the logging framework? We're
looking for an alternative to log4j. Is logkit the way to go
or rather the Avalon framework logger?
> There are some style similarities to the sitemap in logkit.xconf and and
> instrumentation.xconf and to somewhat lesser degree in cocoon.xconf. But
> I don't recall any discussions about it on Cocoon-dev. Stefano sometimes
> refer to long discussions about sitemap design when Cocoon2 was created,
> I have no specific references.
OK, I'll take a look at these files and try to extract the
best-practise patterns.
>> We probably won't integrate the WF with the sitemaps directly.
>> I don't know if you're familiar with the Lenya task concept,
>> this will be the main link between WF and CMS functionality.
>
> Will that mean that the task basically is responsible for sending an
> event to a WF instance,
Probably the component that invokes the task (the TaskAction or the
TaskJob) will be responsible for triggering the event in the WF
instance.
> and that there is a task for creating a new WF
> instance?
Yes. This task will be invoked when a new document is created.
> In a later stage I think it would be a good idea to be able to
> controll the WF engine from flowscripts as well, as flowscripts more and
> more are becomming the prefered way to handle side effects within the
> Cocoon comunity (this is of course not an uncontroversial statment ;) ).
Are you familiar with flowscript? In the mailing list I read that
there's a lack of documentation, I didn't have the time to take a
look at it by now.
> There is also a need for using and presenting the state of an WF
> instance from the sitemap.
This is very easy to achieve. For instance, the WorkflowMenuTransformer
inserts a tag with the current workflow state ID into the menu
(so the state is displayed in the Lenya menubar).
> I saw that you have started a thread about
> the format of the WF instance. Are you planning to make the WF instance
> description available from a generator or what is your idea?
Not directly. You can create a WorkflowDocument (a CMS document wrapper
that is a WF instance) using the WorkflowFactory.
> I also
> wonder what your ideas are about identification
We will use the existing Lenya authentication mechanisms as far as
possible.
> and persistance for WF
> instances.
In our basic implementation, the workflow history file stores the
current state and state variables (see above).
> A WF definition need an identifier as well, I guess that there can be
> several different WF within a CMS so there is a need to be able to refer
> to a specific WF.
Yes, there can be several workflow definition files. They are assigned
to document types (config/doctypes/doctypes.xconf).
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Workflow definition document
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Hi Andreas
Andreas Hartmann wrote:
...
> We decided to restrict the functionality of our interfaces to the
> minimum that is needed for Lenya.
Seem very reasonable.
> My intention was to create a very simple API and a basic implementation
> that can be replaced by an adapter for an existing engine. I kept the
> CMS stuff out of the workflow API for SoC reasons.
>
> I can spend very little time on implementing a flexible or more
> comprehensive solution,
I did not meant that Lenya should contain something that is more
flexible than your a) proposal. Rather that I believe that your a)
proposal would be usefull as is, in other domains.
> but I might be interested in integrating
> an existing engine if this makes Lenya more stable or standards
> compliant.
Even if I'm in general is very much for standard compliance, I have not
been that entusiastic about the WF standards I have seen this far. At
this stage I think that it is better to do something rather minimal.
...
>>> --------------------
>>> a) general + fexible
>>> --------------------
>>
>>
>> I would prefer this solution. As far as I can see, there is nothing
>> in the basic state and transition model, or the workflow interfaces
>> in the CVS that are specific for publishing. And as mentioned above
>> there are so many use cases for WF outside publishing that it IMO
>> would be a good idea to keep the WF engine rather flexible.
>
>
> Actually, I also prefer this one. But my intention is not the
> application outside of Lenya, but the implementation of
> publication-specific conditions and actions.
Yes, it is probably hard to know beforhand about all kinds of
publication-specific conditions and actions that could be needed, so a)
is probably a much better even whithout taking use cases outside
publishing into account.
>
>
> If you really think that the API can be used for other purposes,
> feel free to use it! But I'm afraid the current community won't
> invest much work in making it more flexible than we need for Lenya.
> Of course, if you want to do so - that would be great!
> The more applications there will be, the more consolidated
> code will develop (at least I hope so ...)
For the moment I would be happy with Lenyas WF engine, but as always,
the devil is in the details ;) there might been things that I have
missed, we will see.
>
>> It would also be rather easy to build such a more flexible WF engine
>> as there allready is a framework in Cocoon for building language
>> interpreters. Take a look at the package
>> org.apache.cocoon.components.treeprocessor. Sylvain Wallez wrote the
>> treeprocessor a few years ago as he wanted to have a sitemap
>> interpreter instead of a compiler. Back then there were also
>> discussion about building a XML based flow handeling language within
>> Cocoon, so he wrote a framework that was suposed to be general enough
>> for building general XML configured interpreters that are based on
>> Avalon components.
>
>
> Thanks for the info! I will take a look at the TreeProcessor.
I took a closer look at the TreeProcessor and found out that I prommised
a litle bit to much. Although large part of the framework is rather
general there are a few dependencies on sitemap specific things at some
central positions in the interfaces. This makes it hard to reuse it.
Still I believe that much of the ideas in it would be good to reuse for
a WF engine.
>
>> If you are interested in using the treeprocessor for implementing the
>> WF engine, and more generaly in "Avlonizing" the WF components I
>> would be happy to contribute.
>
>
> At least the latter one would be very interesting. I already thought
> about "Avalonizing" :) the engine.
I would be interested in taking part of that process and has earlier
experience in building Avalon based frameworks. I will be traveling for
the next two weeks, but after that I could spend some time on it.
>
>> Going more into the details in your proposal I think that the main
>> ideas look good. I also think that it could be a good idea to take a
>> close look at the sitemap and try to follow the conventions from it.
>
>
> > It will
> > be much easier to learn Lenya and other Cocoon based framework
> > if there is some common style for all configuration files.
>
> In fact, I already had this idea :)
> The basic structure (declaration of components, usage of components)
> is very similar. I decided against this to keep the files simple,
> but maybe it's really worth a thought to make it similar to sitemaps.
> Is this a general pattern that appears also in other document
> definitions?
There are some style similarities to the sitemap in logkit.xconf and and
instrumentation.xconf and to somewhat lesser degree in cocoon.xconf. But
I don't recall any discussions about it on Cocoon-dev. Stefano sometimes
refer to long discussions about sitemap design when Cocoon2 was created,
I have no specific references.
> Let's see what the others think.
>
>> I also wonder about how you are integrating the WF engine with the
>> sitemaps, I looked in the mail archives and browsed the code and
>> couldn't find anything. Could you please give a link or some
>> description of it.
>
>
> We probably won't integrate the WF with the sitemaps directly.
> I don't know if you're familiar with the Lenya task concept,
> this will be the main link between WF and CMS functionality.
Will that mean that the task basically is responsible for sending an
event to a WF instance, and that there is a task for creating a new WF
instance? In a later stage I think it would be a good idea to be able to
controll the WF engine from flowscripts as well, as flowscripts more and
more are becomming the prefered way to handle side effects within the
Cocoon comunity (this is of course not an uncontroversial statment ;) ).
There is also a need for using and presenting the state of an WF
instance from the sitemap. I saw that you have started a thread about
the format of the WF instance. Are you planning to make the WF instance
description available from a generator or what is your idea? I also
wonder what your ideas are about identification and persistance for WF
instances.
A WF definition need an identifier as well, I guess that there can be
several different WF within a CMS so there is a need to be able to refer
to a specific WF.
>
>
> Andreas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: Workflow definition document
Posted by "Gregor J. Rothfuss" <gr...@wyona.com>.
>>
I can spend very little time on implementing a flexible or more
comprehensive solution, but I might be interested in integrating
an existing engine if this makes Lenya more stable or standards
compliant.
<<
maybe a client would like to help sponsor the necessary manpower..
or enough people in the community chime in :)
> It will
> be much easier to learn Lenya and other Cocoon based framework
> if there is some common style for all configuration files.
+1000
spurious XML dialects are evil.
-gregor
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Workflow definition document
Posted by Andreas Hartmann <an...@apache.org>.
Hi Daniel,
Daniel Fagerstrom wrote:
> Andreas Hartmann wrote:
>
>> Hi Lenya developers,
>
>
> Hi, I'm not a Lenya developer, but I have been lurking on the list for a
> while and am very interested in having a workflow engine that can be
> used from Cocoon. There are numerous use cases for a workflow engine in
> that context besides publishing.
first of all - thanks for your reply and your interest!
We decided to restrict the functionality of our interfaces to the
minimum that is needed for Lenya.
My intention was to create a very simple API and a basic implementation
that can be replaced by an adapter for an existing engine. I kept the
CMS stuff out of the workflow API for SoC reasons.
I can spend very little time on implementing a flexible or more
comprehensive solution, but I might be interested in integrating
an existing engine if this makes Lenya more stable or standards
compliant.
[...]
>> --------------------
>> a) general + fexible
>> --------------------
>
> I would prefer this solution. As far as I can see, there is nothing in
> the basic state and transition model, or the workflow interfaces in the
> CVS that are specific for publishing. And as mentioned above there are
> so many use cases for WF outside publishing that it IMO would be a good
> idea to keep the WF engine rather flexible.
Actually, I also prefer this one. But my intention is not the
application outside of Lenya, but the implementation of
publication-specific conditions and actions.
If you really think that the API can be used for other purposes,
feel free to use it! But I'm afraid the current community won't
invest much work in making it more flexible than we need for Lenya.
Of course, if you want to do so - that would be great!
The more applications there will be, the more consolidated
code will develop (at least I hope so ...)
> It would also be rather easy to build such a more flexible WF engine as
> there allready is a framework in Cocoon for building language
> interpreters. Take a look at the package
> org.apache.cocoon.components.treeprocessor. Sylvain Wallez wrote the
> treeprocessor a few years ago as he wanted to have a sitemap interpreter
> instead of a compiler. Back then there were also discussion about
> building a XML based flow handeling language within Cocoon, so he wrote
> a framework that was suposed to be general enough for building general
> XML configured interpreters that are based on Avalon components.
Thanks for the info! I will take a look at the TreeProcessor.
> If you are interested in using the treeprocessor for implementing the WF
> engine, and more generaly in "Avlonizing" the WF components I would be
> happy to contribute.
At least the latter one would be very interesting. I already thought
about "Avalonizing" :) the engine.
> Going more into the details in your proposal I think that the main ideas
> look good. I also think that it could be a good idea to take a close
> look at the sitemap and try to follow the conventions from it.
> It will
> be much easier to learn Lenya and other Cocoon based framework
> if there is some common style for all configuration files.
In fact, I already had this idea :)
The basic structure (declaration of components, usage of components)
is very similar. I decided against this to keep the files simple,
but maybe it's really worth a thought to make it similar to sitemaps.
Is this a general pattern that appears also in other document
definitions?
Let's see what the others think.
> I also wonder about how you are integrating the WF engine with the
> sitemaps, I looked in the mail archives and browsed the code and
> couldn't find anything. Could you please give a link or some description
> of it.
We probably won't integrate the WF with the sitemaps directly.
I don't know if you're familiar with the Lenya task concept,
this will be the main link between WF and CMS functionality.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Workflow definition document
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Andreas Hartmann wrote:
> Hi Lenya developers,
Hi, I'm not a Lenya developer, but I have been lurking on the list for a
while and am very interested in having a workflow engine that can be
used from Cocoon. There are numerous use cases for a workflow engine in
that context besides publishing. A few examples of such use cases that
we have discussed at my company recently (but implemented without using
a wf engine this far), are:
* We build data warehouses, here we use a WF for keeping track on data
deliveries for data warehouses and for updating data marts that depends
on the data warehouses.
* We administer web questionaries, here we use a WF for keeping track on
interaction with the people that we want to interview.
* In order processing system you need to know in what stage the order is.
> could you please discuss the following draft of a workflow
> definition document:
>
>
>
> --------------------
> a) general + fexible
> --------------------
I would prefer this solution. As far as I can see, there is nothing in
the basic state and transition model, or the workflow interfaces in the
CVS that are specific for publishing. And as mentioned above there are
so many use cases for WF outside publishing that it IMO would be a good
idea to keep the WF engine rather flexible.
It would also be rather easy to build such a more flexible WF engine as
there allready is a framework in Cocoon for building language
interpreters. Take a look at the package
org.apache.cocoon.components.treeprocessor. Sylvain Wallez wrote the
treeprocessor a few years ago as he wanted to have a sitemap interpreter
instead of a compiler. Back then there were also discussion about
building a XML based flow handeling language within Cocoon, so he wrote
a framework that was suposed to be general enough for building general
XML configured interpreters that are based on Avalon components.
A while ago I built a propertary framework for handling time series data
in (pull based) pipelines. I based the "sitemap" interpreter for this
framework on something that is very similar to the treeprocessor, and I
am very happy with the flexibility of this solution. I didn't use the
treeprocessor as I thought that I could manage with something simpler,
but I was wrong got something quite similar to the treeprocessor in the
end :)
If you are interested in using the treeprocessor for implementing the WF
engine, and more generaly in "Avlonizing" the WF components I would be
happy to contribute.
--- o ---
Going more into the details in your proposal I think that the main ideas
look good. I also think that it could be a good idea to take a close
look at the sitemap and try to follow the conventions from it. It will
be much easier to learn Lenya and other Cocoon based framework if there
is some common style for all configuration files.
So something a litle bit more sitemap like could be:
<workflow ...>
<components>
<conditions>
<condition name="role" class="..." logger="..."/>
...
</conditions>
...
<components>
<workflow-definition>
<states>
<state .../>
...
</states>
...
<transitions>
...
<transition event="approve" source="review" destination="live">
<condition type="role" value="manager"/>
<assign variable="is-live" value="true"/>
<action type="cms" value="publish"/>
</transition>
...
</transitions>
</workflow-definition>
</workflow>
<snip/>
-- o --
I also wonder about how you are integrating the WF engine with the
sitemaps, I looked in the mail archives and browsed the code and
couldn't find anything. Could you please give a link or some description
of it.
/Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org