Ticket #2537 (new task)

Opened 7 years ago

Last modified 7 years ago

Reduce boiler plate generic setup code

Reported by: gracinet Owned by: gracinet
Priority: P2 Milestone: CPS 3.6.1
Component: CPSCore Version: 3.5.2
Severity: normal Keywords: generic setup tool adapter

Description (last modified by gracinet) (diff)

Currently, GenericSetup just provides base adapter to subclass. That, and the import step entry function have led to huge code duplication for basic tools whose import is totally generic (properties, subobjects). See this  typical example.

This is really a silly use of the ZCA. One can hope that current (Zope >= 2.12) GenericSetup or CMF versions provide a better system.

We should provide instead:

  • a real, ready-to-rock adapter to register for all these tools. The only thing that differs from one to the other are the NAME and LOGGER_ID attributes. These could be initialized from ZCML, with a new CPS directive, or simply read on the tool in their __init!().
  • a function factory for step points of entry.

This would remove hundreds of useless lines from our code, and replace them with one version ready to follow the path up to current GenericSetup. Of course, care must be taken to do it in the best way for future versions.

Change History

comment:1 Changed 7 years ago by gracinet

  • Description modified (diff)

Formatting, and a bit of clarity

comment:2 Changed 7 years ago by gracinet

Effort started : the generic adapter is in CPSUtil.property, together with a factory that returns export and import step functions.

Demonstration as above in CPSFileMailer (exportimport module replaced by one line in __init___)

comment:3 Changed 7 years ago by gracinet

BTW, there's no direct test (there will at some point), but CPSFileMailer tests play the import step, of course.

comment:4 Changed 7 years ago by gracinet

There's a bug while using the PropertiesSubObjectsXMLAdapter directly. It has a default name attribute : generic.

In turn, this is used by the recursive importObjects function of GenericSetup to decide that the XML file should be called generic.xml in all cases.

Replacing that value by None will fix import of the currently few objects that use it directly

comment:5 Changed 7 years ago by gracinet

Fix pushed. That means that subclasses can't fix for now that name (hence the filename) but that's a very seldom use.

In the future, it'd be easy to add a class-level attribute for this default value (and have it be None in this class), for possible subclasssing.

Note: See TracTickets for help on using tickets.