[quills-dev] Back-porting workflow-aware configuration to Quills 1.7
Jan Hackel bon-list at hackel.nameThu Jul 10 21:55:09 UTC 2008
- Previous message: [quills-dev] Back-porting workflow-aware configuration to Quills 1.7 - patch included
- Next message: [quills-dev] Back-porting workflow-aware configuration to Quills 1.7
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [quills-dev] Back-porting workflow-aware configuration to Quills 1.7 - patch included
- Next message: [quills-dev] Back-porting workflow-aware configuration to Quills 1.7
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the quills-dev mailing list