lenya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hartmann <andr...@apache.org>
Subject Re: Workflow definition document
Date Thu, 05 Jun 2003 12:08:18 GMT
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


Mime
View raw message