Assumptions: You have installed Plone to your machine in (eg) d:\Plone25 and you have checked out your code to the Products folder. You have installed Eclipse 3.2.1 with the WebTools plugin and PyDev plugins
Known Limitations:

1. from Windows you’ll need to do your Subversion stuff via TortiseCVS rather than Eclipse.  I did get around this by creating my Plone product as a separate Eclipse project (in addition to the project setup discussed below) and then using a sync tool (eg SyncBack) to copy the files to the Products folder under Plone.
2. Full debug doesn’t work inside the Products folder.   You can step through unit tests and code under the Zope folder but to get step by step debug working inside Products you’ll need to get the PyDev extensions and follow the instructions here
3. PyDev has trouble with the Python path for the Products folder because Products dir has no __init__.py   If you add this file (can be empty) then autocomplete and import statement check will work.   (Same goes for any Products without init.py)

This HowTo is based on an older guide: http://plone.org/documentation/how-to/developing-plone-with-eclipse-ide

Setting up the environment.

Open Eclipse and choose a workspace directory. Open the PyDev “Perspective” (and close the Java perspective !!)

To enable code completion and launching Python files inside IDE, you need to specify few things.

• Setup available Python interpreters
  1. Window -> Preferences -> PyDev -> Interpreter – Python
  2. Add your Plone interpreter (eg d:\Plone25\python\Python.exe)

Associate page templates to HTML editor

1. Window -> Preferences -> General -> Content Types
2. Open Text -> HTML
   • Add .dtml, .pt and *.cpt
3. Open Text -> CSS
   • Add *.dtml

This gives HTML and CSS code completion (via CNTRL+space) and validation. (NB The TAL attributes will show up as failed validations…)

Setting up the project.

1. Create a PyDev project (call it, say, UNINterface)
   • Uncheck “Use default and enter the Plone install directory eg. d:\Plone25
   • Uncheck “Create default src folder…”

   

1. Right click the project, select Properties, then PyDev – PYTHONPATH
   • Select “Add source folder” and add the
     /Data/Products and
     /Zope/lib/python

   
   At this stage you should be able to open a .py file or .dtml or .css in the correct editor (If you want to choose a specific editor use Right Click -> Open and select the correct editor. That one will become the next default.). Other good things to do. Highlight the name of a Type and press F3. The highlighted class should (eventually) appear in the editor window. Can also do this with variables but it can be slow as the tooling tries to find all the possible types that the variable could be.)

Setting up the Unit Test debug environment.

1. From the menu select Run -> Run..
2. Click Python Run and then the “new” Run Configuration button

Name: “Run Zope Test”

Project: Plone25

Main module: D:\Plone25\Zope\bin\test.py

Click the “Arguments” tab

Base directory: D:\Plone25\Data\bin

Program arguments: -vv –config-file=../etc/zope.conf -m Products.<your-product>

Interpreter: d:\python\python24\python.exe

Click the “Environment” tab

Create two new env. variables

INSTANCE_HOME: D:\Plone25\Data

SOFTWARE_HOME: D:\Plone25\Zope\lib\python

The alternative is to set these as System Variables, then restart Eclipse – This is OK unless you have muliple Zope installations.

1. At this point, if you click “Run” for the new Run configuration Eclipse should automatically run all the tests for your project
2. If you choose Debug instead of Run you can set breakpoints in your tests and Eclipse will take you into the “Debug” perspective – Step by Step debug.

Setting up the server debug environment

1. From the menu select Run -> Run..
2. Click Python Run and then the “new” Run Configuration button Name: “Run Zope Server”Project: Plone25Main module: D:/Plone25/Zope/lib/python/Zope2/Startup/run.py
   

   Click the “Arguments” tab

   Base directory: D:\Plone25\Data\bin

   Program arguments: -C D:\Plone25\Data\etc\zope.conf

   Interpreter: d:\python\python24\python.exe

   Click the “Environment” tab

   Create two new env. variables:

   INSTANCE_HOME: D:\Plone25\Data

   SOFTWARE_HOME: D:\Plone25\Zope\lib\python

   The alternative is to set these as System Variables, then restart Eclipse – This is OK unless you have muliple Zope installations.

3. You can now set Breakpoints in any python module in Zope or Plone and do stepwise debug. (hopefully)

As usual, not having all the history behind me, I am asking questions that many people would already have thought through…Very happy to have my ideas systematicallyterminated.

I’m involved with a group writing an information management system – kind of CMS related. I’ve been mulling over the choice of technology. I’ve been deeply involved in programming J2EE for the past seven years and now am learning to create web apps with Plone and Zope. While I think the “Plope” combination is very powerful I do have some concerns. Here’s my thought dump…

Long term viability: I’m still worried about the nature of Plone as our implementation base. Hearing comments around the office over the past couple of weeks it seems that many of the issues that people struggle with are related to grappling with are to do with
“getting Plone to do what we want”. I wonder if we’d be better off focussing on pure Python and only using Plone / Zope where we absolutely need to. For example, while the workflow built in to Plone is enticing, our workflows are not actually very complicated. As I see it we basically need to be able to creat an object, populated it with data from a web form and then store it, at the same time, notifying a particular user of an event. The user responds, and so on. This could be done quite easily with pure Python objects and, say, an email library. The only thing we then really need Plone for is the http runtime and the ZDB. (And these can be provided by other systems such as Django or Turbogears with MySQL)

If we continue with this technology, would the system needs to be in a state that can be easily handed over to another party for continued maintenance / development if the current team disbanded?

Another issue is the ZDB. While they may be efficient, the IT world has not embraced object databases. Oracle, DB2 and MySQL dominate for good reason. The management of the data is centred onone piece of software. The data can be manipulated, optimised, (and fixed) and viewed independently of the application layer. Data reporting systems can be used without needing to build onto Zope/Plone and without exporting and manipulating XMLised objects.

In my previous job the developers were very keen on Python and Ruby but our clients would be extremely unlikely to accept systems based on those technologies even though they might have many benefits. The key is ownership and maintainability. The same goes for the current system. For how long can we guarantee the availability of Plonedevelopers.

Large, less flexibleorganisations seem to prefer tried and accepted technologies and, in my experience, rarely go with open-source, preferring to pay big dollars for supported software. They would likely prefer more broadly accepted standards such as J2EE which is implemented by a raft of vendors and open source groups, rather than being locked into Plone.

At the very least, our system should be written with portability in mind. If we decide to drop Plone and go with straight Zope or Django or TurboGears then we would be in a better position if as much of our codebase as possible is devoid of Plone dependencies. Part of our system architecture design should work towards encapsulating as much of the system as a simple Python library which is then called by the Plone dependent part.