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

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

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

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

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

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

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

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

Makes the code more efficient, and much more readable.


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

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

Exploring Zope code finally revealed what we needed in the
code, to allow removing the "trick".
It's a "trick" because we have no real reason to call
again the __init__ method of a metaclass: it's nicer to
understand what we need to do and to do it explicitely.

In this case, the __get__ slot was missing after the __bases__
assignement (bases are recomputed and as a result __get__ is
null'ed), and there is a method exposed in Zope's ExtensionClass
to do exactly this and only this.

The InitializeClass calls are included because
ExtensionClass.__init__ calls __class_init__, which sets correctly
roles and security on the class.


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

1) Do not use gc.get_referrers as this is highly inefficient.
(the returned list contains a lot of objects, some of them
are persistent objects, some of them are not classes, etc, etc...
But worse, "dead" objects with a zero reference count can be returned
by this function, and this function would "ressucitate" them.
gc.get_referrers for application code is usually a bad idea)

2) Use instead a Python metaclass to track who's been subclassing
a portal type class, and after a change on the portal type class,
we just call the efficient PortalTypeMetaClass.getSubclassList to
get descendants.


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

it is evil to recreate the attributes during _aq_reset.

Scenario:
 * First call to aq_dynamic
 * aq_portal_type = Base.aq_portal_type
    - inner aq_dynamic business
    - causing an aq_reset call
    - Base.aq_portal_type = {}
    - [...]
    - return
* local aq_portal_type is not anymore Base.aq_portal_type

The symptoms are random, hard to reproduce loud KeyError crashes in
  hasattr(aq_portal_type[aq_key], accessor_name, None)
that disappear on the second try.


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

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

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

* The initial commit

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

This business template is the refactored version of erp5_jquery, and the previous version is still available by installing erp5_jquery_legacy instead of this one.


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

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

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

Sheets into ZODB



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

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

have always been an instance of Expression



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

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

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

* export migrated portal types with new type_class property

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

* remove my_type_factory_method_id from BaseType_view as type_class is replacing this field with portal type classes code

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

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

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

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

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

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

This fixes testInventory and testInventoryModule

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

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

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

FYI, pure python client is also under development:
* http://pypi.python.org/pypi/handlersocket
* https://code.launchpad.net/~songofacandy/+junk/pyhandlersocket


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

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

This fixes testERP5Commerce.

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

Activities could read from the ZODB an state older than the one
that caused the activity to be created, if:
1.Zope client node (node A) processing an activity  message is different
  than the one that created the activity (node B),
2.The object cache for node A contains objects concerning the activity
  message (or its container)
3.The node A hasn't yet received the invalidation message from the ZEO
  server, for instance, if its still on the network layer (kernel buffers,
  routers in between, etc...)

The simplest fix for this issue is sending a synchronous message to the
ZEO server before the beginning of a transaction. This message will act
like a “network barrier”, making sure that any invalidation messages
sent before that point from the ZEO server are already received, and the
transaction can begin with an “updated enough” state.

Additional note from Yoshinori : This patch must be proposed to zope
developpers as soon as possible and see with them if this way is the
best.

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

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

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