Mailing List Archive: Zope: CMF

Adapterizing CMFCore.WorkflowTool

Index | Next | Previous | View Threaded

l at lrowe

Dec 20, 2007, 2:28 AM

Post #1 of 12 (2393 views)
Permalink

Adapterizing CMFCore.WorkflowTool

For the upcoming Plone 3.1 release, we have two PLIPs aimed at
adapterizing workflow lookup: http://plone.org/products/plone/roadmap/217

and adapterizing workflow status and history:
http://plone.org/products/roadmap/221

Ideally these should both go into CMF. What are the current plans for
the next CMF release?

While #221 can probably be deferred for Plone 3.2 and so go straight
into CMFCore, the need for #217 is more immediate, as it would better
support CMFPlacefulWorkflow which is supplied with Plone. Regardless,
the medium term goal is to have the functionality of both in CMFCore, so
feedback from CMF developers would be very welcome.

Laurence

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

y.2007- at wcm-solutions

Dec 30, 2007, 5:45 AM

Post #2 of 12 (2290 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

Hi!

Laurence Rowe wrote:
> For the upcoming Plone 3.1 release, we have two PLIPs aimed at
> adapterizing workflow lookup: http://plone.org/products/plone/roadmap/217

-1

I don't understand the need for this. The workflow tool shipped with
CMFCore implements IConfigurableWorkflowTool. It is responsible for
maintaining the workflow chains. If you want a tool with a different
behavior, why don't you subclass the tool instead of monkey patching or
adapterizing it?

> and adapterizing workflow status and history:
> http://plone.org/products/roadmap/221

+1

I just would prefer named adapters over multi-adapters. And deprecate
getHistoryOf, setStatusOf and getStatusOf.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

l at lrowe

Dec 30, 2007, 10:21 AM

Post #3 of 12 (2299 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

yuppie wrote:
<snip/>
>> and adapterizing workflow status and history:
>> http://plone.org/products/roadmap/221
>
> +1
>
> I just would prefer named adapters over multi-adapters. And deprecate
> getHistoryOf, setStatusOf and getStatusOf.

The problem with using named adapters is that it becomes necessary to
make individual registrations for every workflow id. You could have all
calling code fallback to general interface lookup, but this would make
it pretty much impossible to deprecate getHistoryOf, setStatusOf and
getStatusOf. Perhaps I've missed a better way of handling this?

Laurence

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

y.2007- at wcm-solutions

Dec 30, 2007, 1:28 PM

Post #4 of 12 (2287 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

Laurence Rowe wrote:
> yuppie wrote:
> <snip/>
>>> and adapterizing workflow status and history:
>>> http://plone.org/products/roadmap/221
>>
>> +1
>>
>> I just would prefer named adapters over multi-adapters. And deprecate
>> getHistoryOf, setStatusOf and getStatusOf.
>
> The problem with using named adapters is that it becomes necessary to
> make individual registrations for every workflow id. You could have all
> calling code fallback to general interface lookup, but this would make
> it pretty much impossible to deprecate getHistoryOf, setStatusOf and
> getStatusOf. Perhaps I've missed a better way of handling this?

Now I see why you didn't propose named adapters. But I'm still not happy
with adapting (IContentish, basestring). Did you consider to add getId()
to IWorkflowDefinition and to adapt (IContentish, IWorkflowDefinition)?

Cheers, Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

l at lrowe

Jan 1, 2008, 12:55 PM

Post #5 of 12 (2272 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

yuppie wrote:
> Laurence Rowe wrote:
>> yuppie wrote:
>> <snip/>
>>>> and adapterizing workflow status and history:
>>>> http://plone.org/products/roadmap/221
>>>
>>> +1
>>>
>>> I just would prefer named adapters over multi-adapters. And deprecate
>>> getHistoryOf, setStatusOf and getStatusOf.
>>
>> The problem with using named adapters is that it becomes necessary to
>> make individual registrations for every workflow id. You could have
>> all calling code fallback to general interface lookup, but this would
>> make it pretty much impossible to deprecate getHistoryOf, setStatusOf
>> and getStatusOf. Perhaps I've missed a better way of handling this?
>
> Now I see why you didn't propose named adapters. But I'm still not happy
> with adapting (IContentish, basestring). Did you consider to add getId()
> to IWorkflowDefinition and to adapt (IContentish, IWorkflowDefinition)?

Then I don't see how you would register adapter for a specific (TTW or
generic setup defined) workflow.

Perhaps a named adapter lookup falling back to a plain adapter lookup is
the best solution?

Laurence

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

y.2008 at wcm-solutions

Jan 8, 2008, 11:27 AM

Post #6 of 12 (2258 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

Hi Laurence!

Laurence Rowe wrote:
> yuppie wrote:
>> Now I see why you didn't propose named adapters. But I'm still not
>> happy with adapting (IContentish, basestring). Did you consider to add
>> getId() to IWorkflowDefinition and to adapt (IContentish,
>> IWorkflowDefinition)?
>
> Then I don't see how you would register adapter for a specific (TTW or
> generic setup defined) workflow.
>
> Perhaps a named adapter lookup falling back to a plain adapter lookup is
> the best solution?

All the solutions you propose to solve this look a bit like a hack to me
- I guess because you want to use adapters for something they are not
designed for. AFAICT the default pattern for adapting specific objects
is to use marker interfaces.

Why do we need a different solution for workflows?

(Sorry for not answering earlier.)

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

l at lrowe

Jan 16, 2008, 2:34 AM

Post #7 of 12 (2238 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

yuppie wrote:
> Hi Laurence!
>
>
> Laurence Rowe wrote:
>> yuppie wrote:
>>> Now I see why you didn't propose named adapters. But I'm still not
>>> happy with adapting (IContentish, basestring). Did you consider to
>>> add getId() to IWorkflowDefinition and to adapt (IContentish,
>>> IWorkflowDefinition)?
>>
>> Then I don't see how you would register adapter for a specific (TTW or
>> generic setup defined) workflow.
>>
>> Perhaps a named adapter lookup falling back to a plain adapter lookup
>> is the best solution?
>
> All the solutions you propose to solve this look a bit like a hack to me
> - I guess because you want to use adapters for something they are not
> designed for. AFAICT the default pattern for adapting specific objects
> is to use marker interfaces.
>
> Why do we need a different solution for workflows?

Because they have names already. At the moment an integrator can easily
set up workflows through the web and export a generic setup profile. I'd
like to preserve this way of working.

I'd like to enable the possibility of registering different adapters for
different workflows, but as far as I know there is no easy way of
importing/exporting marker interfaces attached to TTW workflows.

However the solution is a bit ugly, so I guess the best way forward is
making the modifications you suggest. A developer can then register an
adapter that performs named adapter lookups if s/he so wishes.

I'll create a branch and make the changes.

Laurence

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

l at lrowe

Jan 30, 2008, 10:56 AM

Post #8 of 12 (2193 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

I have made the changes on a branch:
http://svn.zope.org/Products.CMFCore/branches/adapterize-wfstatus-wfhistory

This is branched from 2.1 so I could test with Plone. There is no test
coverage for status or history yet. I'll add some if the approach meets
with approval.

Comments appreciated, specifically on:

* I currently adapt based on (IContentish, IWorkflowDefinition) should
this be made more general, i.e. (Interface, IWorkflowDefinition)? Does
anyone workflow anything that is not IContentish?

* Is depricating getStatusOf, setStatusOf, getHistoryOf desirable? I'm
not sure it would serve any particular purpose.

Laurence

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

encolpe.degoute at ingeniweb

Jan 30, 2008, 3:21 PM

Post #9 of 12 (2186 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

Laurence Rowe a �crit :
> I have made the changes on a branch:
> http://svn.zope.org/Products.CMFCore/branches/adapterize-wfstatus-wfhistory
>
> This is branched from 2.1 so I could test with Plone. There is no test
> coverage for status or history yet. I'll add some if the approach meets
> with approval.
>
> Comments appreciated, specifically on:
>
> * I currently adapt based on (IContentish, IWorkflowDefinition) should
> this be made more general, i.e. (Interface, IWorkflowDefinition)? Does
> anyone workflow anything that is not IContentish?

If CMF is focused only on CMS features, you shouldn't have workflow on
something that is not a 'content'. Now, if you was involved in workflow
sprint in Naples, you should know that we want something more powerful
than a workflow focused on content:
http://www.openplans.org/projects/plone-workflows/project-home

> * Is depricating getStatusOf, setStatusOf, getHistoryOf desirable? I'm
> not sure it would serve any particular purpose.

I use these methods during export/import to/from oldier Plone version or
to/from another CMS. It allows more readable code than making low level
programmation to rebuild an history or to force a specific workflow state.

Regards,
--
Encolpe Degoute
INGENIWEB (TM) - S.A.S 50000 Euros - RC B 438 725 632
17 rue Louise Michel - 92300 Levallois Perret - France
web : www.ingeniweb.com - � les Services Web Ing�nieux �
Tel : 01.78.15.24.08 / Fax : 01 47 57 39 14

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

y.2008 at wcm-solutions

Feb 11, 2008, 10:22 AM

Post #10 of 12 (2157 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

Hi!

Laurence Rowe wrote:
> I have made the changes on a branch:
> http://svn.zope.org/Products.CMFCore/branches/adapterize-wfstatus-wfhistory
>
> This is branched from 2.1 so I could test with Plone. There is no test
> coverage for status or history yet. I'll add some if the approach meets
> with approval.

+1

> Comments appreciated, specifically on:
>
> * I currently adapt based on (IContentish, IWorkflowDefinition) should
> this be made more general, i.e. (Interface, IWorkflowDefinition)? Does
> anyone workflow anything that is not IContentish?

IContentish sounds fine. This can easily be changed later or customized
if needed.

> * Is depricating getStatusOf, setStatusOf, getHistoryOf desirable? I'm
> not sure it would serve any particular purpose.

In the long run we want to replace tools by utilities and adapters.
After your change these methods are just small wrappers around adapter
lookups. I think the recommended pattern should be using the adapters
directly, not the tool methods.

Cheers

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

sasha.vincic at valentinewebsystems

Nov 21, 2008, 4:17 AM

Post #11 of 12 (1660 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

Laurence Rowe wrote:
> I have made the changes on a branch:
> http://svn.zope.org/Products.CMFCore/branches/adapterize-wfstatus-wfhistory
>

What is the status of this branch and acceptans of this into trunk?

/Sasha

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Nov 21, 2008, 6:25 AM

Post #12 of 12 (1657 views)
Permalink

Re: Adapterizing CMFCore.WorkflowTool [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 21, 2008, at 13:17 , Sasha Vincic wrote:

> Laurence Rowe wrote:
>> I have made the changes on a branch:
>> http://svn.zope.org/Products.CMFCore/branches/adapterize-wfstatus-wfhistory
>>
>
> What is the status of this branch and acceptans of this into trunk?

Since no one has worked on it for 9 months I'd say the status is
"abandoned". There's also no tests, which is bad.

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkkmxPMACgkQRAx5nvEhZLIk2gCgpczzl2m4mzYgdKHsWvWs2etS
7j4AnivccyNRp+2YXihdloU5InPnKsxl
=llt1
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads