This is still a work in progress

time instead of runtime.

Since the portal type does not change, and since methods are wrapped
individually depending on the portal type, it is safe to do this at
registration time.

It means that no "useless" interactions are attached to objects,
and that the portal type check only happens once in the life of a method.
Overall, this should contribute to better performances.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42726 20353a03-c40f-0410-a6d1-a30d3c3de9de

notify* methods are never called if the guard evaluates to False. This
check looks costly and useless.


The only possibility (?) would be that one of your Interaction workflow guards
checks kw['workflow_method_args'] and returns a different result depending
on when _checkTransitionGuard is called.
That seems like a tricky (wrong? unlikely?) usecase.
If you are in this case, let me know, and if needed I'll engineer a fast guard
check that is only ever checked once.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42725 20353a03-c40f-0410-a6d1-a30d3c3de9de

Correct and update comment: we _do_ use isWorkflowMethodSupported to check the
guard of a transition before running it, check Base.WorkflowMethod implementation.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42724 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42722 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42721 20353a03-c40f-0410-a6d1-a30d3c3de9de

If this is not the case, we should adapt code registrating methods
to skip non-triggers instead of checking invalid transitions all the
time. Hence the assert.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42720 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42285 20353a03-c40f-0410-a6d1-a30d3c3de9de

This fixes several unit tests (with not executable activities) where an object
is created and deleted in the same transaction, whereas an interaction
(ex: document_security_interaction_workflow) creates activities for this object
just before committing. The 'flush' happens earlier.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42281 20353a03-c40f-0410-a6d1-a30d3c3de9de

Add a special way to disable interactions for temporary documents, as this pattern is frequently used in many ERP5 applications, and it is a big bottleneck in the performance.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@39043 20353a03-c40f-0410-a6d1-a30d3c3de9de

What's the point? Mostly cleaning up pyflakes output:
now, running it on those files does not give anymore cluttered output,
but raises (almost) only valid human errors.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33558 20353a03-c40f-0410-a6d1-a30d3c3de9de

Create a new ERP5Type/Workflow.py file to house all changes needed as we progressively remove DCWorkflow dependencies. For now it contains the non-patches part of patches/DCWorkflow.py and a conditional replacement for addWorkflowFactory() function that disappeared on CMF 2. Adjust other import locations to point to this function. Adjust ERP5Type product initialization to register Zope2-style factories for workflows registered with the substitute addWorkflowFactory when on CMF2 (approved by jm and jerome)

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30010 20353a03-c40f-0410-a6d1-a30d3c3de9de

before-commit-hook API for the transaction object changed. Temporarily patch transaction on Zope 2.8 with the new API and adapt all uses (approved by jm)

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@29871 20353a03-c40f-0410-a6d1-a30d3c3de9de

Concentrate all imports of addWorkflowFactory to a location under our control. For CMF 2.x we will emulate this function by creating actual Zope2 Factories for our workflows.

git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/portal_types@29477 20353a03-c40f-0410-a6d1-a30d3c3de9de

On the way to Zope 2.12, Reform imports, specially from Globals (replacing it with Products.ERP5Type.Globals on the products that depend on ERP5Type), convert Interface uses to zope.interfaces, and remove CMFMailIn references with blessings from Jerome.

git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/portal_types@29459 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@26943 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@26928 20353a03-c40f-0410-a6d1-a30d3c3de9de

Add a test for this expected behaviour


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@24192 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@24190 20353a03-c40f-0410-a6d1-a30d3c3de9de

this Executing Type allow to execute a interaction script at the end of transaction


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@24180 20353a03-c40f-0410-a6d1-a30d3c3de9de

Be consistent with CMFActivity: use unrestrictedTraverse to get script's context. Security checks will still happen when script is executed.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@20440 20353a03-c40f-0410-a6d1-a30d3c3de9de

This megapatch changes the way accessors are generated. Instead of generating all accessors for each portal type, we only generate tuples which are put in a kind of tuple cache. The idea is to minimise the number of objects which are created and use objects which are as small as possible. Then, the next time aq_dynamic is invoked, we dynamically create a new accessor instance based on the parameters provided in the tuple. This way, it is possible to reduce the memory footprint of ERP5 by 200 MB at least and create only those accessors which are needed. 
In addition, accessors are now generated per portal_type and per class. This way, if the class of a portal type changes in a system, different accessors are generated and there is no risk of falling into a problem of "first argument of method XXX must be of type YYY".
The downside is currently a possible speed decrease of 2-3%.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@17606 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@15978 20353a03-c40f-0410-a6d1-a30d3c3de9de

New WorkflowMethod implementation. This new implementation solves most issues which existed previously and related to multiple workflows for a single workflow method ID. It should also be faster but will require some more work so that changes in workflow definition are reflected automatically in workflow methods registration. Added support in interaction workflows for once per transaction execution and regular expressions in trigger method IDs.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@15825 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@13852 20353a03-c40f-0410-a6d1-a30d3c3de9de

Repare broken image.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@6277 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@4392 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@4209 20353a03-c40f-0410-a6d1-a30d3c3de9de

do not catch ObjectMoved


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@4034 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@4033 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@3450 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@2690 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@2675 20353a03-c40f-0410-a6d1-a30d3c3de9de