lenya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Workflow definition document
Date Thu, 05 Jun 2003 12:50:57 GMT
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. 



>> 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.



To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org

View raw message