1. 07 Jul, 2011 2 commits
  2. 06 Jul, 2011 1 commit
  3. 04 Jul, 2011 1 commit
  4. 13 May, 2011 1 commit
  5. 11 Apr, 2011 1 commit
  6. 05 Apr, 2011 1 commit
  7. 30 Mar, 2011 1 commit
  8. 25 Mar, 2011 3 commits
  9. 02 Mar, 2011 1 commit
  10. 25 Feb, 2011 2 commits
  11. 12 Feb, 2011 1 commit
  12. 07 Feb, 2011 1 commit
  13. 02 Feb, 2011 1 commit
  14. 01 Feb, 2011 2 commits
    • Nicolas Dumazet's avatar
      Last chunk of portal type classes / zodb property sheets. · d02ba206
      Nicolas Dumazet authored
      After this, all ERP5 objects become instances of portal type classes
      
      Preferences:
      * all the trickery for preferences is gone and is handled by a specific
        accessor holder holding all preference methods
      
      Property holders
      * our Base.aq_portal_type property holders are not used anymore:
        the "property holder" becomes the portal type class itself and the
        set of accessor_holder classes in the mro of the portal type class:
        portal-type-specific methods are on the portal type class, while
        portal-type-independant method are put on the accessor holder ancestors
      * the portal type meta class now also inherits from "PropertyHolder" to
        provide the same introspection interface and methods.
        (In the future this class / interface will need to be refined)
      
      Bootstrap/migration:
      * bootstrapping/migration from older instances: provide with code able to
        import XML from ERP5/bootstrap/ to load necessary tools from almost any
        instance state
      * migrate in BusinessTemplate installation code all non-portal type classes
        objects to portal type classes
      * Change the way Tools are installed when creating a site, so that we create
        directly portal type classes objects instead of Documents
      
      Accessors:
      * add a generatePortalTypeAccessors method on the portal type class to generate
        portal-type-specific accessors
      * associate BaseAccessorHolder to all portal type classes to contain
        all common category related accessors
      * change the way workflow methods are generated to bind them directly on
        the portal type class
      * disable Base._aq_dynamic (while still keeping its code for debugging and
        reference, this can be cleanup up later)
      
      
      git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42902 20353a03-c40f-0410-a6d1-a30d3c3de9de
      d02ba206
    • Nicolas Dumazet's avatar
  15. 31 Jan, 2011 1 commit
  16. 06 Jan, 2011 1 commit
  17. 05 Jan, 2011 1 commit
  18. 07 Dec, 2010 4 commits
  19. 06 Dec, 2010 1 commit
  20. 01 Dec, 2010 2 commits
  21. 29 Oct, 2010 1 commit
  22. 28 Oct, 2010 1 commit
    • Julien Muchembled's avatar
      Fix some bootstrap issues · e12f1516
      Julien Muchembled authored
      - fix recursive call of Base._aq_dynamic
      - revert r39457 ("__of__ has no reason to trigger portal_type loading.")
      - avoid problematic and useless interaction/reindexation
        while migrating a portal type
      
      Steps to reproduce were:
      0. make sure your browser is already logged (Manager may be required)
      1. runUnitTest --save --portal_id=erp5 testBusinessTemplate
      2. runUnitTest --load
      3. open /erp5/portal_templates/view
      
      Note: some errors were random.
      
      git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@39615 20353a03-c40f-0410-a6d1-a30d3c3de9de
      e12f1516
  23. 27 Oct, 2010 3 commits
  24. 22 Oct, 2010 1 commit
  25. 21 Oct, 2010 2 commits
  26. 20 Oct, 2010 1 commit
    • Nicolas Dumazet's avatar
      Portal type classes. · a94f18cd
      Nicolas Dumazet authored
      - All ERP5 objects now become instances of erp5.portal_type.**
        Being an instance of a portal type does no longer only mean
        "having a portal_type attribute", it now also means deriving from
        a specific, ad-hoc Python class for this portal type.
      
      - erp5.portal_type module is built dynamically and its objects
        are classes subclassing the physical Document classes on disk.
      
      - ERP5Type.Document fate:
        + classes previously stored here are gone
        + newTempXXX methods stay, and will work correctly. But a call
          to such a method will require an BaseType object in
          portal_types module.
        + other stuff is gone
      
      - Temporary documents will be instances of erp5.temp_portal_type.*
        All classes in this submodule subclass the respective
        erp5.portal_type.* persistent class
      
      - Documents that were created dynamically without a product path
        (for instance, those created with ClassTool) are now stored
        in a specific module, erp5.document.*
      
      
      Migration after this revision should be handled automatically,
      but updating beyond this point should nonetheless not be done
      carelessly.
      
      Expected changes in XML for business templates:
       - Classpath of documents:
            ERP5Type.Document.XXX -> erp5.portal_type.XXX
       - new "type_class" attribute on Portal Type Objects (BaseType Documents)
      
      
      
      git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@39371 20353a03-c40f-0410-a6d1-a30d3c3de9de
      a94f18cd
  27. 05 Oct, 2010 2 commits