erp5_catalog: Refactor _catalogObject List to remove the need to copy and patch

Create FilterDict and Filter class which would be used to imitate the behaviour
of filter_dict for Catalog.

/suggested by @jm

product/ZSQLCatalog/SQLCatalog.py

@@ -737,10 +737,11 @@ class Catalog(Folder,
         f.write('  </property>\n')
     # XXX Although filters are not properties, output filters here.
     # XXX Ideally, filters should be properties in Z SQL Methods, shouldn't they?
-    if hasattr(self, 'filter_dict'):
+    filter_dict = self._getFilterDict()
+    if filter_dict:
       filter_list = []
-      for filter_id in self.filter_dict.keys():
-        filter_definition = self.filter_dict[filter_id]
+      for filter_id in filter_dict.keys():
+        filter_definition = filter_dict[filter_id]
         filter_list.append((filter_id, filter_definition))
       # Sort for easy diff
       filter_list.sort(key=lambda x: x[0])
@@ -1601,7 +1602,7 @@ class Catalog(Folder,
 
     with (noReadOnlyTransactionCache if disable_cache else
           readOnlyTransactionCache)():
-      filter_dict = self.filter_dict
+      filter_dict = self._getFilterDict()
       catalogged_object_list_cache = {}
       for method_name in method_id_list:
         # We will check if there is an filter on this
@@ -1670,18 +1671,10 @@ class Catalog(Folder,
           continue
 
         #LOG('catalogObjectList', 0, 'method_name = %s' % (method_name,))
-        method = getattr(self, method_name)
-        if method.meta_type in ("Z SQL Method", "LDIF Method"):
-          # Build the dictionnary of values
-          arguments = method.arguments_src.split()
-        elif method.meta_type == "Script (Python)":
-          arguments = \
-            method.func_code.co_varnames[:method.func_code.co_argcount]
-        else:
-          arguments = []
+        method = self._getCatalogMethod(method_name)
         kw = {x: LazyIndexationParameterList(catalogged_object_list,
                                              x, argument_cache)
-          for x in arguments}
+          for x in self._getCatalogMethodArgumentList(method)}
 
         # Alter/Create row
         try:
@@ -1705,6 +1698,20 @@ class Catalog(Folder,
   if psyco is not None:
     psyco.bind(_catalogObjectList)
 
+  def _getFilterDict(self):
+    return self.filter_dict
+
+  def _getCatalogMethodArgumentList(self, method_name):
+    if method.meta_type in ("Z SQL Method", "LDIF Method"):
+      # Build the dictionnary of values
+      return method.arguments_src.split()
+    elif method.meta_type == "Script (Python)":
+      return method.func_code.co_varnames[:method.func_code.co_argcount]
+    return ()
+
+  def _getCatalogMethod(self, method_name):
+    return getattr(self, method_name)
+
   security.declarePrivate('beforeUncatalogObject')
   def beforeUncatalogObject(self, path=None,uid=None):
     """

[Vincent Pelletier]

To squash in the commit wich did the code duplication to begin with.

Also, I'm not sure about the changes in ZSQLCatalog: this kind of make it depend on the product only being used in ERP5, which I think we avoided so far, and is the reason we have it separate from ERP5Catalog (the product) at all. If we decide we do not care about non-ERP5 uses, then more could be factorised. I do not know if we can decide not to care. @jm: ideas ?

[Ayush Tiwari]

Squashing this in the commit where code duplication began with will end up adding all changes regarding FilterDict to the commit where we create ERP5Catalog hence making one commit where we will have multiple changes like ERP5ifying catalog, change tests accordingly, change Business Template accordingly. I wanted to keep the changes made regarding FilterDict as it is more independent and some changes made due to FilterDict don't concern ERP5Catalog.

[Vincent Pelletier]

If one does not work without the other, I believe they belong to the same commit.

Or, if it is possible to do all FilterDict changes before ERP5-ing catalog, that is fine for me too: then you can put all edits needed for that change in a commit before the catalog ERP5-ification one.

Keeping commits small is good. But commits must be small because code changes needed to achive each desired feature change are small. When many changes are too interconnected, the a large commit makes more sense.

Also, I think _catalogObjectList removal does not belong to filter evolution, so anyway this commit needs a bit of rework.