Writing Plone portlets is still pretty hard. Even as an experienced Plone programmer I usually have to check Martin Aspeli's book or check older code in order to remember how the implementation must look like. My general impression about the Plone portlets implementation: too complex, over-designed and unfriendly to average developers. So this blog entry tells you about some rough ideas about how portlet writing in Plone should look like from the prospective of a developer.

What are portlets?

Portlets are conceptually just a component providing a piece of HTML content that is rendered by some manager within some context. The concept of a (browser) view is basically pretty similar to the functionality of a portlet.

Usecases

A simple portlet implemented with a template

In Plone 2 portlets were just simple page templates providing a dedicated macro "portlet". So portlet were very easy to write and configure (beside Plone 2 had no notion of portlet assigment). Within Plone I want to be able to write a small piece of template implementing the functionality and I want to be able to register it using ZCML with:

<plone:portlet
    for="my.package.interfaces.ISomething"
    title="My cool portlet"
    template="something_portlet.pt"
/>

No Python code involved - just a template and an easy snippet of ZCML registration

A simple portlet with some Python code

A portlet implementation might need some additional logic (because we don't want complex logic within our templates. So our implementation may look like a brower view:

class SomethingPortlet(SomeMagicPortletBase):

     template = ViewPageTemplateFile('something_portlet.pt')

     def helperMethod1(self):
       .....

     def helperMethod2(self):
      ...

And the registration with Plone will look similar to a browser view:

<plone:portlet
    for="my.package.interfaces.ISomething"
    title="My cool portlet"
    class="something.SomethingPortlet"
/>

A portlet with configuration parameters

Complex portlet may need persistent parameters like #items to be displayed with the portlet. This is expressed through a schema (also similar with browser views):

class ISomethingPortlet(Interface):

     number_items = zope.schema.IntegerField(..)

class SomethingPortlet(SomeMagicPortletBase):

     template = ViewPageTemplateFile('something_portlet.pt')
     implements(number_items)

     def helperMethod1(self):
       .....

     def helperMethod2(self):
      ...

 The ZCML registration is the same as above.

Do we need anything more?

No, I don't think so.

As a portlet developer I do not have to care with the approach above about

• assignment
• add forms
• edit form

All those three aspects can be handled under the hood. Add and edit forms can be auto-generated using formlib or z3c.form. Assignment is a standard issue that must not be exposed to the portlet developer in any way. 

The current Plone portlet machinery allows the portlet developer all kind of flexibility but the developer has no chance avoid the complexity. The programming of browser views within the Zope world is pretty easy to understand for average programmers. Using the same concepts without adding new concepts for writing portlets would make it much easier for people without high-level programming skills.

Uncovered by this blog entry remains the aspects that deal with assignment issues and the implementation of portlet managers...

Another side note: the same ideas could apply to viewlets or better: pieces of HTML code injected into HTML pages based on some policy and magic. The viewlet implementation is also pretty complex and we need a more strict separation between the core implementation of a portlet or viewlet and aspects like assignment or registration with a particular portlet or viewlet manager....

This blog entry is perhaps a bit weird and not thought to the end but I hope it might be useful for further discussions on how to make Plone more approachable for average-skilled developers.