A prototype of pure ZODB source code management for ERP5 (mostly required for Cloud deployments and 24/7 operation).
Migration idea:
Anything which looks like source code in ERP5 (HTML, py, etc.) should be serialized automatically with 2 forks (à la MacOS 6/7/8/9). One fork represents the source code (ex. Order.py) and another fork represents extra metadata which is managed by ZODB (ex. Order.xml).
ERP5 source code is thus moved (in the sens of git) from Products/ERP5/Document/Order.py to bt5/erp5_core_component/.../Order.py. No history is thus lost. It also leads to a quite simple structure since everything which was in Products is now moved to bt5 without any dependency problem.
In the end, only ERP5Type remains. Everything else in ERP5 can be hot updated with nice transactional feature.
First we have to start with Extensions and Documents (present in bt5). Then we should add all files present in Productrs/*/Document and Productrs/*/Tool. Then Mixins and Interfaces. At the end, Accessors. The core of ERP5.
The core of ERP5 will eventually move from ERP5Type to a python library. A wrapper product (ERP5Site) main remain though for compatibility with Zope 2.X.
How to develop in this environment:
- all coding, debuging and testing should be handled TTW with a good AJAX editor or with external editor. The ERP5 runtime is supposed to be located remotely on the Cloud, no longer on a laptop or local server
- users of kate, emacs, vi, etc. should remote mount ZODB to edit text files through WebDAV. FUSE/DAVS works well enough these days for this purpose
git integration
- this topic is still under discussion since ZODB plays here the role
<value><string>ERP5 Text Document</string></value>
</item>
<item>
<key><string>description</string></key>
<value><string>An Accessor Component defines how to get and set properties of a document. It is used usually by Document Classes which implement properties of a property sheet.</string></value>
<value><string>ERP5 Text Document</string></value>
</item>
<item>
<key><string>description</string></key>
<value><string>All persistent ERP5 objects with a user interface are documents. A Document Component contains a python class which defines the behaviour of persistent ERP5 documents stored in ZODB. </string></value>
<value><string>ERP5 Text Document</string></value>
</item>
<item>
<key><string>description</string></key>
<value><string>An Extension Component may contain arbitrary python code. Each function defined in an Extension Component can be published in ERP5 through so-called "External Method" objects. The use of Extension Component and External Methods is not recommended and will eventually be replaced with a more document centric approach.</string></value>
<value><string>ERP5 Text Document</string></value>
</item>
<item>
<key><string>description</string></key>
<value><string>A mixin component usually provides a complete or partial, reusable and extensible implementation of an interface. By subclassing a mixin, a Document Component can provide an interface.</string></value>
<value><string>ERP5 Text Document</string></value>
</item>
<item>
<key><string>description</string></key>
<value><string>A test component is a collection of subclasses of ERP5TestCase which define abstract tests to cover unit, functional or naming specifications.</string></value>
