Portlet love
"Therefore, since brevity is the soul of wit, And tediousness the limbs and outward flourishes, I will be brief" - Shakespeare, Hamlet, 1603
In a community where people donate their time and genius to develop software like Plone, the worst thing one can do is complain without offering help or advise, because that just doesn't help the evolution of the software at all! So apologies for complaining without suggesting what I think would be better. I would like to help the evolution of Plone in a constructive way so let met try again ;-)
First, let me clarify my position somewhat. I don't think that going back to Plone 2.5 style portlets is the way to go. It is unwieldy for all the reasons mentioned by Martin and Geir in their posts. At the same time I don't think it should be that complicated to create a simple portlet in Plone 3.0. So both Martin and Geir suggested I use the "not recommended" classic portlet. I admit this is very easy but it doesn't solve my use cases from a development point of view. I want to register a portlet by name and use a Zope 3 view for any python logic. So the classic portlet does not give me the same flexiblity offered to other developers that use the new portlet engine and the new dance is to complex.
The new portlets engine is not so complex that you can't get your head around it or get used to it. I still managed to rewrite my portlet in less than an hour. It is just not as simple as it should be. Ideally (for simple cases) one shouldn't need more than one zcml, a view class, an interface and a template. Even this still sounds like to much and I believe this is something that Grok is trying to solve. It shouldn't be necessary to define assignment, renderer, addview and editview if I don't need it. And it shouldn't be necessary to define something like a NullAddForm. In this sense the portlet engine introduces to much new terminology when you don't need it.
Maybe it was unfair of me to shout at the portlets engine specifically - I'm sure there are other warts. What I would like to emphasize though is that we don't use the power of Zope 3 to build a framework with unnecessary layers of indirection that alienates new developers even further. We should use the power of Zope 3 to make things simple and more powerful at the same time. And it should be fun and easy to learn.
