Reading a recent comment about portlets in Plone 3, i was baffled by the negativity, until i realized that the man is simply suffering from the slight misconception that the classic portlet is something he is not supposed to use. (probably due to me not writing the tutorial Martin rightfully expects me to write)

Complexity

Roche is unhappy that portlets are now more complex than they were before.
Fair enough. This is a pattern we have seen for thousands of years. To accomodate new needs or desires, growth or increasing complexity of society, technology grows more complex.

Let's use flight as an example: A hot air balloon is a fairly simple instrument, and can be built by almost anyone with motivation and a bit of resources. But even though hot air balloons can be perfectly good (even the best) for many use cases,  they also have limitations; they are  slow, they have limited cargo capabilities and are hard to navigate. Upgrading to a simple aeroplane may be tempting as it can help resolve these issues.  But upgrading from a balloon to a plane will also lead to more complex technology; aerodynamics, combustion engines, airfield construction… Moving another step up the ladder into organised passenger traffic, you'll end up with airports, air traffic controllers, ticket management systems and lots of organizational issues too.

The neat thing is that even in today's world of organized passenger air traffic, there is room for the hot air balloon. In many scenarios, the simple, flexible and agile tool (not to mention cheap), is preferable to complex engineering.

Give me a classic!

Many of us have been suffering from the lack of a proper portlet management system in Plone. Given a deployment of any reasonable complexity, it was just too much to handle with the tools we had.
The reason i am writing this is that some people seem to be suffering from the misconception that the old-style portlet, the classic portlet, — the hot air balloon of portlets, is deprecated and not recommended in real-life use. This is completely wrong! Given the late trend of integrators being suspicious of the added complexity and allegedly lacking TTW-support of Plone 3, i feel it is necessary to clarify this bit for the non-developers out there:

The classic portlet, a first-class Plone citizen:

A lot of effort (Kudos to Martin) has been put into making it simple to work with portlets for integrators. And even better: in addition to being able to continue working with the portlets as before you get to combine it with the powers the new portlet engine brings, and add extra free superpowers without having to break a sweat: Even with single-template-based classic portlets you get new stuff from plone.portlets and plone 3: 

• Your portlet can be assigned (and unassigned or blocked) in the UI, in Plone, not just in ZMI valley where no real user will ever venture.
• Your portlet can now be assigned to users' dashboards
• Your portlet can now be assigned to groups of users
• Your portlet can now be assigned to content types

In exchange for all these new features, you have to sacrifice exactly *nothing*. You don't even have to rewrite your template. You don't have to touch  three python classes or any zcml files. — Simply add a classic portlet in the plone interface, paste the path to your template and you are good to go!

In addition to all this, developers will also soon start distributing usable portlets as eggs, so you can plug all sorts of extra functionality on top — and you'll still not be chewing on the extra complexity.

--
Geir Bækholt