[Yanel-dev] Workflow

[Josias Thöny]

Michael Wechner wrote:
> Josias Thöny wrote:
> 
>> Hi devs,
>>
>> Do we already have a concept about the workflow?
>> Should it be implemented as a Workflowable interface?
>>
>> Here is a proposal for the "simplest possible" Workflowable interface:
>>
>>     void publish();
>>     void deactivate();
>>     void edit(); // invoke edit event to allow re-publishing
>>     boolean isLive();
>>     boolean canPublish();
>>     View getLiveView(String viewid);
>>
>> A possible implementation could use a specific revision of a resource 
>> as the "live" version. This would require that a Workflowable resource 
>> is also Versionable.
>>
>> The problem with such a "hard-coded" interface is that it's maybe not 
>> easy to extend to a more generic workflow schema (e.g. with 
>> submit/reject or arbitrary workflow transitions).
> 
> 
> agreed. It seems to me that workflow is actually completely independent 
> of a resource except for the connection between version and live 
> workflow status. What if we only create an interface/method for 
> getLiveVersion() and do the rest orthogonal?

How would that work for resources which have a workflow, but no versioning?
I'm thinking about a completely dynamic resource like e.g. a clock. Such 
a resource still could be published/deactivated, just to enable/disable 
its appearance in the live area. But it doesn't support versioning, so I 
don't know what the getLiveVersion() method would do.

Another question is if it's necessary to support different workflow 
schemas depending on the resource type, like e.g.:
   ResourceType A: submit/review/publish/deactivate
   ResourceType B: publish/deactivate
If we need this, it might have some implications for the design of the 
whole workflow system.

WDYT?

> 
>>
>> Another question is how to access the live version from the browser. 
>> Michi suggested to create a LiveResource. IIUC this resource would 
>> catch all urls which start with a certain prefix: /live/** (is that 
>> possible at all?)

I have some doubts about the LiveResource.
If we have the url /live/foo.html, I think it's not sufficient that the 
LiveResource just requests the live revision of foo.html, but it also 
has to pass the information live/authoring to the resource foo.html.
This is necessary because a dynamic resource may have to know the "area".
If resource A includes resource B (e.g. via xinclude), yanel has to make 
sure that when the live version of A is generated, the live version of B 
is included. This means that A has to know the "area" and also pass it to B.
This seems to require that yanel has some concept of live/authoring 
areas. I'm not sure how it could be accomplished just by having a 
LiveResource. Maybe with a parameter yanel.area=live which would be 
passed from the LiveResource to /foo.html?

Josias

> 
> 
> I think we can solve that with the "chain of responsibility"
> 
>> In the example /live/foo.html it would return the live version of 
>> /foo.html.
> 
> 
> right
> 
>>
>> Any comments?
>>
>> Josias
>>
>>
>> _______________________________________________
>> Yanel-development mailing list
>> Yanel-development at wyona.com
>> http://wyona.com/cgi-bin/mailman/listinfo/yanel-development
>>
> 
>