Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: CMF

[dev] .zexp imports and notifyWorkflowCreated

 

 

Zope cmf RSS feed   Index | Next | Previous | View Threaded


y.2009 at wcm-solutions

Feb 18, 2009, 4:04 AM

Post #1 of 20 (2620 views)
Permalink
[dev] .zexp imports and notifyWorkflowCreated

Hi!


Moving the notifyWorkflowCreated call from _finishConstruction to the
IObjectAddedEvent subscriber changed the behavior of .zexp imports: The
workflow state is now always reset to the initial state. AFAICT that's
no useful behavior for imports.

This is caused by the fact that the notifyCreated method of WorkflowTool
always resets the workflow states.

Is that a feature or a bug of notifyCreated? Is anybody using
notifyCreated for resetting workflow states?

Where is the best place to fix this? Should IObjectAddedEvent be
triggered on imports? Should the subscriber call notifyWorkflowCreated
if the object already has a workflow history? Should
notifyWorkflowCreated call WorkflowTool.notifyCreated if the object
already has a workflow history? Should WorkflowTool.notifyCreated call
notifyCreated of workflows that already have a state? Should
notifyCreated of workflows keep existing states untouched?


AFAICS the easiest way to fix this is changing
WorkflowTool.notifyCreated, making sure it only calls notifyCreated for
workflows without a state in the workflow history.

Any objections or better ideas?


Cheers,

Yuppie

_______________________________________________
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


tseaver at palladion

Feb 18, 2009, 9:37 AM

Post #2 of 20 (2552 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

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

yuppie wrote:
> Moving the notifyWorkflowCreated call from _finishConstruction to the
> IObjectAddedEvent subscriber changed the behavior of .zexp imports: The
> workflow state is now always reset to the initial state. AFAICT that's
> no useful behavior for imports.
>
> This is caused by the fact that the notifyCreated method of WorkflowTool
> always resets the workflow states.
>
> Is that a feature or a bug of notifyCreated? Is anybody using
> notifyCreated for resetting workflow states?
>
> Where is the best place to fix this? Should IObjectAddedEvent be
> triggered on imports? Should the subscriber call notifyWorkflowCreated
> if the object already has a workflow history? Should
> notifyWorkflowCreated call WorkflowTool.notifyCreated if the object
> already has a workflow history? Should WorkflowTool.notifyCreated call
> notifyCreated of workflows that already have a state? Should
> notifyCreated of workflows keep existing states untouched?
>
>
> AFAICS the easiest way to fix this is changing
> WorkflowTool.notifyCreated, making sure it only calls notifyCreated for
> workflows without a state in the workflow history.

+1.

- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJnEdu+gerLs4ltQ4RAoMSAKCEyP2CN5EfonXqkZSIGjLfHLqM+wCfYtEC
/pYBguVEQhbri7sVoAtbJsM=
=AwXA
-----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


tseaver at palladion

Feb 18, 2009, 9:37 AM

Post #3 of 20 (2553 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

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

yuppie wrote:
> Moving the notifyWorkflowCreated call from _finishConstruction to the
> IObjectAddedEvent subscriber changed the behavior of .zexp imports: The
> workflow state is now always reset to the initial state. AFAICT that's
> no useful behavior for imports.
>
> This is caused by the fact that the notifyCreated method of WorkflowTool
> always resets the workflow states.
>
> Is that a feature or a bug of notifyCreated? Is anybody using
> notifyCreated for resetting workflow states?
>
> Where is the best place to fix this? Should IObjectAddedEvent be
> triggered on imports? Should the subscriber call notifyWorkflowCreated
> if the object already has a workflow history? Should
> notifyWorkflowCreated call WorkflowTool.notifyCreated if the object
> already has a workflow history? Should WorkflowTool.notifyCreated call
> notifyCreated of workflows that already have a state? Should
> notifyCreated of workflows keep existing states untouched?
>
>
> AFAICS the easiest way to fix this is changing
> WorkflowTool.notifyCreated, making sure it only calls notifyCreated for
> workflows without a state in the workflow history.

+1.

- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJnEdu+gerLs4ltQ4RAoMSAKCEyP2CN5EfonXqkZSIGjLfHLqM+wCfYtEC
/pYBguVEQhbri7sVoAtbJsM=
=AwXA
-----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


y.2009 at wcm-solutions

Feb 18, 2009, 12:35 PM

Post #4 of 20 (2553 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Hi!


Tres Seaver wrote:
> yuppie wrote:
>> Moving the notifyWorkflowCreated call from _finishConstruction to the
>> IObjectAddedEvent subscriber changed the behavior of .zexp imports: The
>> workflow state is now always reset to the initial state. AFAICT that's
>> no useful behavior for imports.
>>
>> This is caused by the fact that the notifyCreated method of WorkflowTool
>> always resets the workflow states.
>>
>> Is that a feature or a bug of notifyCreated? Is anybody using
>> notifyCreated for resetting workflow states?

It turned out that CMF itself uses notifyCreated for resetting workflow
states :(

That's how copy and paste resets the workflow state.

>> Where is the best place to fix this? Should IObjectAddedEvent be
>> triggered on imports? Should the subscriber call notifyWorkflowCreated
>> if the object already has a workflow history? Should
>> notifyWorkflowCreated call WorkflowTool.notifyCreated if the object
>> already has a workflow history? Should WorkflowTool.notifyCreated call
>> notifyCreated of workflows that already have a state? Should
>> notifyCreated of workflows keep existing states untouched?
>>
>>
>> AFAICS the easiest way to fix this is changing
>> WorkflowTool.notifyCreated, making sure it only calls notifyCreated for
>> workflows without a state in the workflow history.
>
> +1.

This alone will not work.

Does it make sense to keep old workflow history records after copy and
paste? Or can we just remove the complete workflow_history attribute
before notifyCreated is called?

If the subscriber for IObjectCopiedEvent removes the workflow_history
everything seems to work fine.


Cheers,

Yuppie

_______________________________________________
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


wichert at wiggy

Feb 18, 2009, 12:51 PM

Post #5 of 20 (2550 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Previously yuppie wrote:
> Tres Seaver wrote:
> > yuppie wrote:
> >> Moving the notifyWorkflowCreated call from _finishConstruction to the
> >> IObjectAddedEvent subscriber changed the behavior of .zexp imports: The
> >> workflow state is now always reset to the initial state. AFAICT that's
> >> no useful behavior for imports.
> >>
> >> This is caused by the fact that the notifyCreated method of WorkflowTool
> >> always resets the workflow states.
> >>
> >> Is that a feature or a bug of notifyCreated? Is anybody using
> >> notifyCreated for resetting workflow states?
>
> It turned out that CMF itself uses notifyCreated for resetting workflow
> states :(
>
> That's how copy and paste resets the workflow state.

Which is argueably a mis-feature: it means you are not just doing a copy
and paste, but a copy, paste and modify.

> >> Where is the best place to fix this? Should IObjectAddedEvent be
> >> triggered on imports? Should the subscriber call notifyWorkflowCreated
> >> if the object already has a workflow history? Should
> >> notifyWorkflowCreated call WorkflowTool.notifyCreated if the object
> >> already has a workflow history? Should WorkflowTool.notifyCreated call
> >> notifyCreated of workflows that already have a state? Should
> >> notifyCreated of workflows keep existing states untouched?
> >>
> >>
> >> AFAICS the easiest way to fix this is changing
> >> WorkflowTool.notifyCreated, making sure it only calls notifyCreated for
> >> workflows without a state in the workflow history.
> >
> > +1.
>
> This alone will not work.
>
> Does it make sense to keep old workflow history records after copy and
> paste? Or can we just remove the complete workflow_history attribute
> before notifyCreated is called?

In my opinion a copy should produce a full copy, including all state and
history.

Wichert.

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
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


andrew at sawdog

Feb 18, 2009, 12:56 PM

Post #6 of 20 (2554 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

On 2/18/09 12:35 PM, "yuppie" <y.2009 [at] wcm-solutions> wrote:

> Does it make sense to keep old workflow history records after copy and
> paste? Or can we just remove the complete workflow_history attribute
> before notifyCreated is called?
I think it shouldn't be kept...and over time this history tends to get quite
large. On my last 2 projects, we have had to address this by changing the
default implementation.
>
> If the subscriber for IObjectCopiedEvent removes the workflow_history
> everything seems to work fine.
>
+1
>
> Cheers,
>
> Yuppie
>
> _______________________________________________
> 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


_______________________________________________
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


y.2009 at wcm-solutions

Feb 18, 2009, 1:14 PM

Post #7 of 20 (2551 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Hi!


Wichert Akkerman wrote:
> Previously yuppie wrote:
>> Does it make sense to keep old workflow history records after copy and
>> paste? Or can we just remove the complete workflow_history attribute
>> before notifyCreated is called?
>
> In my opinion a copy should produce a full copy, including all state and
> history.

There are several tests for the current behavior in test_Image, so it is
intended behavior.

Do you propose to change the current policy?


Cheers,

Yuppie

_______________________________________________
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


dieter at handshake

Feb 21, 2009, 4:24 AM

Post #8 of 20 (2535 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Wichert Akkerman wrote at 2009-2-18 21:51 +0100:
> ...
>> That's how copy and paste resets the workflow state.
>
>Which is argueably a mis-feature: it means you are not just doing a copy
>and paste, but a copy, paste and modify.

> ...
>In my opinion a copy should produce a full copy, including all state and
>history.

For some workflows, it may not be adequate to retain the state
after a copy.

Consider a publication workflow with a site organized
along subjects with different subject reviewers.
Object "o" is released in subject "s1". Now it is copied
to subject "s2". I think it is obvious that "o" needs a review
at its new place.


In addition: I is highly doubtfull that the "creation_date"
of the copy should be the same as the creation date of the original.

At least in our contexts, copies are usually made to be modified
later (slightly). For this use case, the "creation_date" should
be set to the time the copy was created *and* the copy
should start in the initial state.



--
Dieter
_______________________________________________
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


charlie at begeistert

Feb 23, 2009, 11:25 AM

Post #9 of 20 (2528 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Am 18.02.2009 um 21:51 schrieb Wichert Akkerman:

> In my opinion a copy should produce a full copy, including all state
> and
> history.


Yes, in the technical sense of .copy() but I'm not sure if that is
what I as a user expect in a CMS. Do I really want an exact duplicate
of everything or perhaps a new object with the content of the old? If
the original object has already been published should my new object
also be published? If so surely I'm breaking with the workflow
principle.

In my experience (and I'm not just talking about how I do things)
copies are usually made with the original object being archived as a
sort of security blanket in case something goes wrong.

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226



_______________________________________________
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


r.ritz at biologie

Feb 25, 2009, 12:59 AM

Post #10 of 20 (2522 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Charlie Clark wrote:
> Am 18.02.2009 um 21:51 schrieb Wichert Akkerman:
>
>> In my opinion a copy should produce a full copy, including all state
>> and
>> history.

Not sure I would agree here.
For a move (cut&paste) yes but for a copy I think
there are too many different use cases to justify
your claim above.

>
>
> Yes, in the technical sense of .copy() but I'm not sure if that is
> what I as a user expect in a CMS. Do I really want an exact duplicate
> of everything or perhaps a new object with the content of the old? If
> the original object has already been published should my new object
> also be published? If so surely I'm breaking with the workflow
> principle.
>
> In my experience (and I'm not just talking about how I do things)
> copies are usually made with the original object being archived as a
> sort of security blanket in case something goes wrong.


... and not to forget the common

copy/paste/modify

pattern to create new content.

Here as well I'd say starting out with the initial
workflow state (and new creation date/creator settings)
is the right thing to do.

Just my 2 cents,

Raphael



>
> Charlie
> --
> Charlie Clark
> Helmholtzstr. 20
> Düsseldorf
> D- 40215
> Tel: +49-211-938-5360
> GSM: +49-178-782-6226
>
>
>
> _______________________________________________
> 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
>

_______________________________________________
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


wichert at wiggy

Feb 25, 2009, 5:18 AM

Post #11 of 20 (2519 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Previously Raphael Ritz wrote:
> Charlie Clark wrote:
> > Am 18.02.2009 um 21:51 schrieb Wichert Akkerman:
> >
> >> In my opinion a copy should produce a full copy, including all state
> >> and
> >> history.
>
> Not sure I would agree here.
> For a move (cut&paste) yes but for a copy I think
> there are too many different use cases to justify
> your claim above.

There are many use cases for both options. One aspect is that it is
extremely hard to not get the current behaviour. We had to hire Philipp
to write z3c.unconfigure for us just to be able to create a system
to prevent CMF from making changes on copies.

Wichert

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
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


charlie at begeistert

Feb 25, 2009, 5:43 AM

Post #12 of 20 (2519 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Am 25.02.2009 um 14:18 schrieb Wichert Akkerman:

> There are many use cases for both options. One aspect is that it is
> extremely hard to not get the current behaviour. We had to hire
> Philipp
> to write z3c.unconfigure for us just to be able to create a system
> to prevent CMF from making changes on copies.


First of all I'm not sure if that's such a bad thing! ;-)

But the solution would probably be making this behaviour configurable
somewhere in the workflow tool.

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226



_______________________________________________
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


r.ritz at biologie

Feb 25, 2009, 6:52 AM

Post #13 of 20 (2519 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Wichert Akkerman wrote:
> Previously Raphael Ritz wrote:
>> Charlie Clark wrote:
>>> Am 18.02.2009 um 21:51 schrieb Wichert Akkerman:
>>>
>>>> In my opinion a copy should produce a full copy, including all state
>>>> and
>>>> history.
>> Not sure I would agree here.
>> For a move (cut&paste) yes but for a copy I think
>> there are too many different use cases to justify
>> your claim above.
>
> There are many use cases for both options. One aspect is that it is
> extremely hard to not get the current behaviour.

There I do agree and I also more than once had
the wish for more flexibility/configurability.

> We had to hire Philipp
> to write z3c.unconfigure for us just to be able to create a system
> to prevent CMF from making changes on copies.
>

:-(

Raphael

> Wichert
>

_______________________________________________
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


wichert at wiggy

Feb 25, 2009, 7:10 AM

Post #14 of 20 (2516 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Previously Charlie Clark wrote:
>
> Am 25.02.2009 um 14:18 schrieb Wichert Akkerman:
>
> > There are many use cases for both options. One aspect is that it is
> > extremely hard to not get the current behaviour. We had to hire
> > Philipp
> > to write z3c.unconfigure for us just to be able to create a system
> > to prevent CMF from making changes on copies.
>
>
> First of all I'm not sure if that's such a bad thing! ;-)
>
> But the solution would probably be making this behaviour configurable
> somewhere in the workflow tool.

The workflow tool is not a factor at all here. The problem is that CMF
registers some event handlers that do things like clear workflow status
and local roles when you create a copy.

Wichert.

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
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


charlie at begeistert

Feb 25, 2009, 7:26 AM

Post #15 of 20 (2516 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Am 25.02.2009 um 16:10 schrieb Wichert Akkerman:

> The workflow tool is not a factor at all here. The problem is that CMF
> registers some event handlers that do things like clear workflow
> status
> and local roles when you create a copy.


I realise that but surely the handlers can have a default behaviour
that can be changed depending on the configuration?

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226



_______________________________________________
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


wichert at wiggy

Feb 25, 2009, 8:48 AM

Post #16 of 20 (2515 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Previously Charlie Clark wrote:
> Am 25.02.2009 um 16:10 schrieb Wichert Akkerman:
> > The workflow tool is not a factor at all here. The problem is that CMF
> > registers some event handlers that do things like clear workflow
> > status
> > and local roles when you create a copy.
>
> I realise that but surely the handlers can have a default behaviour
> that can be changed depending on the configuration?

In my opinion they should not be globally registered at all, but
available for registration in a local site manager. CMFDefault could
then do that registration for its needs.

Wichert.

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
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


tseaver at palladion

Feb 25, 2009, 9:15 AM

Post #17 of 20 (2514 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

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

Wichert Akkerman wrote:
> Previously Charlie Clark wrote:
>> Am 25.02.2009 um 16:10 schrieb Wichert Akkerman:
>>> The workflow tool is not a factor at all here. The problem is that CMF
>>> registers some event handlers that do things like clear workflow
>>> status
>>> and local roles when you create a copy.
>> I realise that but surely the handlers can have a default behaviour
>> that can be changed depending on the configuration?
>
> In my opinion they should not be globally registered at all, but
> available for registration in a local site manager. CMFDefault could
> then do that registration for its needs.

You are in the cleft stick created by the paradox of "reusable
configuration" (an oxymoron, even). The other alternative is to *not*
<include/> the configuration from CMFDefault, but copy and tweak it for
your own app.


Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJpXzP+gerLs4ltQ4RAnfeAKDVHNWHME5cFFuY+r0V3gtQcU7r3gCgrC3N
DudQiq3r8xkvq2dbu0kwE6U=
=hywa
-----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


tseaver at palladion

Feb 25, 2009, 9:15 AM

Post #18 of 20 (2470 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

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

Wichert Akkerman wrote:
> Previously Charlie Clark wrote:
>> Am 25.02.2009 um 16:10 schrieb Wichert Akkerman:
>>> The workflow tool is not a factor at all here. The problem is that CMF
>>> registers some event handlers that do things like clear workflow
>>> status
>>> and local roles when you create a copy.
>> I realise that but surely the handlers can have a default behaviour
>> that can be changed depending on the configuration?
>
> In my opinion they should not be globally registered at all, but
> available for registration in a local site manager. CMFDefault could
> then do that registration for its needs.

You are in the cleft stick created by the paradox of "reusable
configuration" (an oxymoron, even). The other alternative is to *not*
<include/> the configuration from CMFDefault, but copy and tweak it for
your own app.


Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJpXzP+gerLs4ltQ4RAnfeAKDVHNWHME5cFFuY+r0V3gtQcU7r3gCgrC3N
DudQiq3r8xkvq2dbu0kwE6U=
=hywa
-----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


wichert at wiggy

Feb 25, 2009, 11:04 AM

Post #19 of 20 (2508 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Previously Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Wichert Akkerman wrote:
> > Previously Charlie Clark wrote:
> >> Am 25.02.2009 um 16:10 schrieb Wichert Akkerman:
> >>> The workflow tool is not a factor at all here. The problem is that CMF
> >>> registers some event handlers that do things like clear workflow
> >>> status
> >>> and local roles when you create a copy.
> >> I realise that but surely the handlers can have a default behaviour
> >> that can be changed depending on the configuration?
> >
> > In my opinion they should not be globally registered at all, but
> > available for registration in a local site manager. CMFDefault could
> > then do that registration for its needs.
>
> You are in the cleft stick created by the paradox of "reusable
> configuration" (an oxymoron, even). The other alternative is to *not*
> <include/> the configuration from CMFDefault, but copy and tweak it for
> your own app.

Not including CMFDefault is entirely reasonable. There are two problems
though:

- CMFDefault is in the Products namespace, so five will load its zcml
automatically.

- some of these are in CMFCore (handleDynamicTypeCopiedEvent for
example, which zaps local roles from copies). Asking people to
copy CMFCore configuration for a reasonably common use case is
not desirable imho.

Wichert.

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
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


wichert at wiggy

Feb 25, 2009, 11:04 AM

Post #20 of 20 (2506 views)
Permalink
Re: [dev] .zexp imports and notifyWorkflowCreated [In reply to]

Previously Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Wichert Akkerman wrote:
> > Previously Charlie Clark wrote:
> >> Am 25.02.2009 um 16:10 schrieb Wichert Akkerman:
> >>> The workflow tool is not a factor at all here. The problem is that CMF
> >>> registers some event handlers that do things like clear workflow
> >>> status
> >>> and local roles when you create a copy.
> >> I realise that but surely the handlers can have a default behaviour
> >> that can be changed depending on the configuration?
> >
> > In my opinion they should not be globally registered at all, but
> > available for registration in a local site manager. CMFDefault could
> > then do that registration for its needs.
>
> You are in the cleft stick created by the paradox of "reusable
> configuration" (an oxymoron, even). The other alternative is to *not*
> <include/> the configuration from CMFDefault, but copy and tweak it for
> your own app.

Not including CMFDefault is entirely reasonable. There are two problems
though:

- CMFDefault is in the Products namespace, so five will load its zcml
automatically.

- some of these are in CMFCore (handleDynamicTypeCopiedEvent for
example, which zaps local roles from copies). Asking people to
copy CMFCore configuration for a reasonably common use case is
not desirable imho.

Wichert.

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
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

Zope cmf RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.