Context

A GenericSetup handler gets passed a context when called. This context is not the Plone Site or some other content. It is a special GenericSetup context, as defined in GenericSetup/context.py. One of the things you can do with that context is passing it some text for its logger so you get some messages in your log files and in the GenericSetup log:

logger = context.getLogger('eXtremeManagement')
logger.info('eXtremeManagement_various step imported')

Various import steps

When you apply a GenericSetup profile (base or extension does not matter) all registered import steps are executed. So if you have an extension profile that only has a propertiestool.xml file, still all import steps (which can be a few dozen) are run. If all authors of those import steps have done their work correctly, all but one exit immediately as they realize they do not need to do anything.

I will quote Rob Miller here:

It is the responsibility of an import step's implementation to ensure that it is indeed appropriate to perform its actions during any given invocation of the step.

All of the XML-based import steps already do this; they check for the existence of a specific XML file, and if they find it they perform the action. If they do not find the file, no problem, they do nothing.

The so-called importVarious steps, i.e. any step that uses a plain old python function as its handler (as opposed to building on the existing XML parsing infrastructure), must perform this check explicitly. you could restrict it to only running when the intended profile is the one being imported, or you could check for the existence of a specific file within the profile. I like the latter choice.

The summary in my own words: if you want to be a good CMF citizen, you had better make sure that the importVarious step of your profile (or any other import step you define yourself) is only executed when your profile is applied and not when the profile of some unrelated product is applied.

So, taking some pointers from how CMFPlone and CMFEditions do it, I fixed eXtremeManagement. I added a file profiles/default/extrememanagement_various.txt. This can remain empty but it is clearer to add a comment, like this:

The eXtremeManagement_various step is run if this file is present in
the profile.

Then I changed setuphandlers.py:

def importVarious(context):
    # Only run step if a flag file is present
    if context.readDataFile('extrememanagement_various.txt') is None:
        return

For reference, this is the profiles/default/import_steps.xml file that tells GenericSetup about this handler:

  
    
    
    
    Import steps that couldn't be mapped to other handlers.
  

So if you have a CMF/Plone product which defines an own import step (like import various, but it can be a totally different step) please make sure that this step only runs when your own profile is applied.

Upgrade profiles

GenericSetup now has support for profiles that you can use to upgrade a product, instead of applying the complete profile again. I only looked at the code and have not actually tried this. But this is absolutely something I want to use in eXtremeManagement too. So I will probably write about that later.

Preface

This report describes my final assignment for my study Informatics at the Rotterdam Institute for Informatics Studies (RIVIO) of the Hogeschool Rotterdam. The assignment lasted from February till June 2007. It was carried out for web development company Zest Software in Hoogvliet, The Netherlands. I have been working there since November 2005. Previous reports for school of my work for Zest Software (including this report) can be found on my website.

The main subject of this report is eXtremeManagement. This is a project management tool for the open source content management system Plone. At Zest Software we use this tool on a daily basis to keep track of what our customers want and how much time we have worked for them.

This eXtremeManagement tool can use some updates, which is the goal of this assignment. The focus is on the underlying technology: using more and more features made available by newer versions of Plone and the Zope web development framework that Plone is built on. Also some user interface improvements will be made.

I thank Hans Manni from RIVIO for keeping me on track for finishing my study. I thank Aad van Raamt for being the second teacher next to Hans on the committee. I thank Jean-Paul and Esther Ladage for giving me the opportunity to work on eXtremeManagement for five months. I thank Reinout for the photo on the front page. I thank my colleagues from all over the world for their feedback, their own additions to eXtremeManagement and for making Zest Software a very nice team to work and have fun with.

Conclusion

eXtremeManagement has been given a thorough cleanup. It runs on the current Plone 3.0 beta. Where useful, Zope 3 technologies have been put to good use. Personally, I have learned a lot about these new software versions and I am sharing that knowledge on my weblog and in mailing lists. At Zest Software we are happily using the latest version of eXtremeManagement and are full of ideas for further improvement.

Some recommendations and further actions to take:

• Release a new version of eXtremeManagement soon: it is ready.
• Building on the foundation laid during this assignment, do more work on the user interface. There are lots of ideas floating around. See Future plans (Appendix A).
• Once Plone 3.0 is officially out, copy the current subversion trunk to a maintenance branch and continue development for Plone 3.0 only on trunk.

In closing, I will say I had a great time with eXtremeManagement and its users and co-developers on the mailing list. eXtremeManagement is a rocking product, ready to handle the future.

Abstract

This report describes my final assignment for school, which is: improve the eXtremeManagement tool: a project management tool based on Extreme Programming principles and running on content management system Plone.

The Introduction (chapter 1) paints the landscape of this assignment. What is Zope? What is Plone? What is eXtremeManagement? How do they fit together?

I made some improvements to the User Interface (chapter 2). Most of the original ideas there were not implemented however, for various reasons, ranging from simple lack of time to fresh insights that invalidated the original plan. The focus of the assignment was shifted to improving the core, instead of the front door.

Plone 3.0 (chapter 3) tells the tale of getting eXtremeManagement ready to run on the new (still in beta status) version 3.0 of Plone. I did some standard fixes applicable to all third party Plone products. I also did some other changes that were found to be needed. Finally I added an improvement to core Plone to make this upgrade easier for other products.

With Zope 3 (chapter 4) we come to the heart of the matter. More than originally envisioned the focus needed to be put here. I added marker and functional interfaces. I created browser views to make a clearer Model-View-Controller distinction. I introduced annotations for keeping track of estimates and hours worked. All three work together to make a far cleaner version of eXtremeManagement than was there at the beginning of this assignment.

I draw the Conclusion (chapter 5) that eXtremeManagement is clean and future-proof and that I have learned a lot in this assignment.

Samenvatting

In dit rapport doe ik verslag van mijn afstudeeropdracht voor de studie Informatica aan de Hogeschool Rotterdam. Ik verbeter de eXtremeManagement tool: een project management tool gebaseerd op Extreme Programming principes en draaiend op het content management systeem Plone.

De Introductie (hoofdstuk 1) schetst de achtergrond van deze opdracht. Wat is Zope? Wat is Plone? Wat is eXtremeManagement? Hoe passen ze in elkaar?

Ik heb wat verbeteringen aangebracht in de gebruikersinterface (hoofdstuk 2). De meeste oorspronkelijke plannen werden niet uitgevoerd, om redenen uiteenlopend van simpel tijdgebrek tot nieuwe inzichten die het originele idee onderuit haalden. De focus van de opdracht verschoof daarmee naar het verbeteren van de kern, in plaats van het mooi maken van de buitenkant.

Plone 3.0 (hoofdstuk 3) vertelt het verhaal van het geschikt maken van eXtremeManagement voor de nieuwe versie 3.0 van Plone, die overigens nog de beta status heeft. Ik heb wat standaardaanpassingen doorgevoerd die alle Plone producten van derden moeten doen. Ik heb ook andere veranderingen gedaan die nodig bleken te zijn. Tenslotte heb ik een verbetering aan de kern van Plone bijgedragen om deze aanpassingen voor 3.0 simpeler te maken voor andere producten.

Met Zope 3 (hoofdstuk 4) komen we bij het hart van de zaak. Meer dan oorspronkelijk gedacht, moest de focus op dit deel gericht worden. Ik heb markeer- en functionele interfaces toegevoegd. Ik heb browser views gemaakt om een duidelijkere scheiding te brengen tussen data, presentatie en logica (Model-View-Controller). Ik heb annotaties ingebracht voor het bijhouden van inschattingen en gewerkte uren. Deze wijzigingen leveren samen een veel schonere versie van eXtremeManagement op dan er was bij de start van de afstudeeropdracht.

Ik trek de conclusie (hoofdstuk 5) dat eXtremeManagement schoon en toekomstklaar is en dat ik veel heb geleerd bij deze opdracht.

General actions

The general steps that every product needs while upgrading from Plone 2.5 to Plone 3.0 are described in the Upgrade guide on plone.org.

Some steps were already taken for Plone 2.5, like setting up the workflows with GenericSetup. Some steps are very simple. An example is that this:

get_transaction().commit(1)

needs to be replaced with:

transaction.commit(1)  

The other ones that needed checking in eXtremeManagement were:

• Searching users/groups via the Membership tool is deprecated; it turns out eXtremeManagement does not use any of the deprecated methods, so fifteen minutes of checking was all that was needed here.

• Portlets have a new infrastructure. Needed action: check that our classic portlets still work in Plone 3.0. They turn out to work fine. In the future we may want to investigate what the benefits of switching to the new portlet system are. A downside is that this would be incompatible with Plone 2.5, so it would require a separate branch.

• main_template.pt now uses Zope 3 viewlets. eXtremeManagement is not using an own version of that template, so no action was needed. In fact, we were not even using that template, which does not sound like the best idea. So I changed our templates to use the page layout as given by the main_template.

• The "Sharing" tab is now a global action. In previous Plone versions you had to explicitly add a Sharing action to your content type if you wanted to see the sharing tab when viewing that content in the Plone user interface. On the sharing tab you can share this content with others. Specifically in the case of eXtremeManagement: we have this tab on Projects, so we can give developers the Employee role and assign Tasks to them.

  On Plone 3.0 this action is now always available. This means that currently some of our content types actually list this tab twice, as they explicitly add it to themselves already. The problem now is that you cannot actually do this correctly on Plone 2.5 and 3.0 at the same time: either you have no sharing tab in 2.5 or you have two sharing tabs in 3.0. Since 3.0 is beta still, I opted to have it working correctly in Plone 2.5 only. Once Plone 3.0 is officially released, we can easily fix this on a branch. Or probably: at that point we can move 2.5 compatibility to its own branch and have trunk specifically for 3.0 support.

More fixes

There were some other steps that needed to be taken before eXtremeManagement would work on Plone 3.0. Some might need to be added to the general list and some may be specific for eXtremeManagement.

-  Finish
+  Finish