Portlet insanity in Plone 3

So I just started migrating my first product to Plone 3. I get an AttributeError on right_slots so the first thing it seems I need to migrate are portlets. I've heard the portlet engine mentioned before so I'm not confused yet. I head over to the documentation section on plone.org and find a tutorial on overriding portlets in Plone 3.0. I couldn't find any docs on creating a new portlet. At least this tutorial points me to the plone.app.portlets package. For a brief moment I stare at the products in parts/plone in my buildout directory until I realize this is egg land. Looking at the portlets package I immediately realise that portlets are now Zope 3 views. I'm fairly familiar with those since I've been using them in Plone 2.5 projects for a while now.

I pick the news portlet as example and open up news.py. I close it immediately after all the unfamiliar classes in there jumps at me like a pack of wild dogs. Mmm, the login portlet seems like a more basic starting point. Not! These bloody dogs will follow you no matter what portlet view you open. My immediate reaction is that this is insanity. Something that used to be a single template is now an interface, at least 3 view classes namely Assignment, Renderer and AddForm and an unnecessary complex zcml directive. Wait I'm not done yet. You still need to define a GenericSetup profile and register the profile. This is insane. I wonder how long this feeling will last until I bear this burden like a chastising monk and even start to praise the glorious separation that is now required to make portlets. I must resist.

The most basic portlet should be no more difficult to write than a couple of lines of HMTL and TAL. I really beg whoever developed this to consider an approach that favours convention over configuration. It should not be this difficult to write a portlet. This is not better. It might be more flexible, probably infinitely so, but it is not better software.

I do realize that you can do portlets pre-3-era style but this is not really recommended. The point of my blog post is that one should really balance pristine framework and pragmatism. We shouldn't make it more difficult for new developers to use our framework. Maybe this level of separation is not pristine ...

The rest of the migration was pretty straightforward. I didn't have to modify any of my Archetypes content types. Not that I would have minded, providing that it was simpler than what I just encountered in the portlets code. Retaining Archetypes was a wise and pragmatic decision. Turning portlets into a something that now requires an in depth knowledge of Zope 3 was not!