Skip to content.

Etria Lists

 

[quills-dev] Back-porting workflow-aware configuration to Quills 1.7

Jan Hackel bon-list at hackel.name
Thu Jul 10 21:55:09 UTC 2008


On Thursday 10 July 2008 02:00:47 Tim Hicks wrote:
> ... I don't think we should be deprecating the workflow methods simply
> because of one particular use case.

It is not actually *one* particular use case but any workflow which draft 
states do not have an action "publish" and which published states do not have 
an action "retract".  There are quite some of them. For Plone 3 these are 
plone_workflow, one_state_workflow and intranet_workflow.

Anyway, the problem is not that Quills distinguishes between draft and 
published entries. It is that the methods "publish" and "retract" are much to 
naive about Plone's workflows. Plone itself does not provide operations for 
navigation to a particular workflow state, because these would be far from 
being trivial (not the difficulty of implementing these, but the mess the 
senseless firing of transition actions could cause, not to speak of 
ambiguities while selecting transition paths). My point is: workflow 
transitions should be made by means of plone_workflow by the user.

This does not threat the idea of having draft documents. The mapping from 
draft/published states to plone workflow states works quite well. But IMO it 
should be a read-only API for the reason given above.

I see that this conflicts with the remote blogging API. I see no easy solution 
though: It is either remote blogging or arbitrary workflows. The user must 
decide. Maybe the workflow affecting operations should be moved to the remote 
blogging product?

> Workflow is important to me, and 
> important to people who have designed remote blogging APIs, apparently.

I agree. Though they probably never though the "publish" parameter of their 
API would be implemented with such a monster as plone_workflow ;-)

> Perhaps a better approach for you would be
> to try to arrange for your weblog-ish objects to declare themselves as
> implementing the subset of quills interfaces that excludes the workflow
> behaviour.  Does that sound doable?

I cannot quite follow. I only wanted to have the workflow-awareness of 
QuillsEnabled in Quills 1.*. The modifications do that, I think. I can remove 
the deprecation warnings though. However the user should be warned, that 
calling this two operations is asking for trouble. If not in a warning then 
perhaps in the docsting?

Jan Hackel




More information about the quills-dev mailing list