3.7. Future proofing

As Plone progresses towards Zope 3, there are some general principles you should keep in mind to make sure your code is "future proof" and won't need to be refactored in the near future. This list may grow, but briefly:

• Look around you! A lot of problems have been solved in CMF, in Zope 3, or by other Python or JavaScript libraries. Before you start inventing something new that the community will have to maintain, consider carefully whether you can re-use something else.
• Declare interfaces for new (or existing) code. In general, any new component should use a well thought-out interface. A class should be registered as a factory for an adapter, and any code using that class should use the interface directly, instantiating the class through the component architecture rather than use the class constructor directly. This will make code much easier to refactor and much easier to override.
• Similarly, where existing tools and objects have interfaces (the CMF tools all have interfaces starting with CMF 1.6, for example), instantiate the objects through the component architecture, not directly from the classes.
• Don't add new Script (Python)'s. In general, any view logic should be in a Zope 3 view. Generic functionality should use adapters or utilities.
• We only ever use DTML for email handling (because it's better preserving whitespace than page templates), and even there we keep it to a minimum. DTML is hard to debug and maintain, and is most definitely frowned upon.
• Use Zope 3 naming conventions for filenames and package layout.

Next: Debugging Previous: Adapters