[Framework-Team] Re: Review on PLIP #118: Portlets engine based on PlonePortlets and Viewlets

Martin Aspeli optilude at gmx.net
Sat Sep 23 21:10:48 UTC 2006


Hi Rocky & co,

Thanks for the review :)
> I followed the bundle notes to discover how to actually activate the
> portlets (in my plone site by default there weren't really any working
> portlets but I assume this was intentional and of course will not be the
> case in the final implementation).  Once the classic portlets were
> activated, things looked pretty typical for Plone.

Yes, we need to write a migration step to put the old portlets back. 
That is trivial, though.

> It was nice to see a UI for managing portlets, of course the current UI
> is rather crude.  I would love to see an ajax-enabled UI for managing
> portlets, but I believe such an amount of work could be a fairly big
> undertaking.

Actually, some drag-and-drop management of portlets is desired and may 
well happen. If it can't happen in time, we certainly want to clean up 
the existing UI which has undergone work only to make it functional, not 
pretty.

> So, now to see how (if) the goals are met:
> 
>   #1: Increase ability to customize
> In my mind this goal has been capture extremely well.  Since the very
> backbone of this new portlet architecture uses the Zope 3 CA, swapping
> out, replacing, customizing all comes very easily and very naturally on
> many different levels.  This goal is met.

A good example of this is how easy it was to make the 'management' view 
of a portlet column (aka portlet manager). This uses the same basic 
rendering as the column is normally using, but plugs in a different 
template and content provider - it's all just one registration.

>   #2: Improve control
> The new portlet architecture provided here gives developers extreme
> control over everything mainly for the same reasons as #1.  This goal is
> met.

:)

>   #3: Improve Plone configuration UI story
> Considering Plone doesn't currently have a configuration UI story for
> configuring portlets, it's not terribly difficult to improve on it.  I
> would say that the current UI offered by this plip is certainly much
> better than nothing.  But it is quite crude and certainly should have
> some level of polish before fully integrated.  As mentioned before,
> ideally it be architected to use AJAX capabilities to provide a full
> user experience.  But I understand (or assume) that is beyond the scope
> of this plip.  So in my opinion a simple level of polish would suffice.
> As long as that is done, this goal is met.

As I said, UI polish and probably some AJAX is expected.

>   #4: Prevent over-complication
> This goal unfortunately hasn't been met very well.  In my opinion the
> new mechanics of integrating Zope 3 CA techniques used in this plip have
> increased the complication of setting up portlets by several magnitudes.
> Of course it wasn't hard to do this since the current method of defining
> portlets and setting them up is extremely simple.  This goal has not
> been adequately met.

I kind of contest this point. If you want to make portlets the old way 
(a template), there is no difference. The only difference is that 
instead of going to the ZMI and editing a property, you add a "classic 
portlet" from within the Plone UI and point it at your template.

But - there are things you can do with portlets now that is more 
powerful than what you could do before. Doing so requires the following:

  - An interface describing the schema of the configurable aspects of 
your portlet (could be just a marker)

  - A simple content class implementing this schema (normally just a 
class with a few attributes, and two properties)

  - An add view, with the appropriate view registration

  - An edit view, with the appropriate view registration

Note that both of these have simple base classes, so it's normally just 
a couple of lines of code + ZCML.

  - A content provider (a view) + a template (normally) for rendering 
the actual portlet

You can see a full portlet in

http://svn.plone.org/svn/plone/plone.app.portlets/trunk/plone/app/portlets/portlets/classic.py

The ZCML is the top part of

http://svn.plone.org/svn/plone/plone.app.portlets/trunk/plone/app/portlets/portlets/configure.zcml

There are several parts here, but that is only because we are separating 
concerns, Zope 3 style. I still fully expect integrator-type people to 
keep writing template-based portlets, in which case they will never have 
to touch any of this. But those who want to write more powerful, 
efficient and flexible portlets will be able to do so.

For example, I want to write a portlet that is essentially just a 
reference to a Smart Folder, which can list its content (so the portlet 
is just a view on the Smart Folder); or, one that points to a Document 
and can render its text in an appropriate font. All that is very easy 
because of the decoupling in the plone.portlets infrastructure.

>   #5: Good test coverage
> From my perusal of the code and functionality the current tests seem to
> a great job of ensuring quality.  In one of the notes or somewhere I saw
> that there is even more planning of adding tests which will further
> ensure quality.  This goal is well met.

Test coverage has been improved a lot in the past couple of weeks, and 
I'm quite happy with it. There is also a set of "canonical" tests for 
the two portlet types there already, which I believe will serve as good 
boilerplate for other people writing portlets and wanting to write tests 
for those.

> Soo... what's my overall feeling?  4 out of 5 goals well met.  The
> stickler here is #4 where the new architecture increases complexity
> substantially.  But it is the opinion of this plip reviewer that the
> pro's of this plip far outweigh this.  So personally I'm willing to live
> with the increase in complication for the sake of such powerful
> functionality.  And of course with #3 we do want to see at least a
> minimal set of UI polish.

+1

> Note:
> On a code level I have to admit that the last thing that kind of makes
> me think, "couldn't this be done a little better?" is the usage of
> strings for categories.  Seems to me that we should be using interfaces
> or utilities here for this.  But that could well be the fact that I've
> been wearing my Zope 3 goggles for so long I tend to think everything
> needs to be zope3-ified.

I'd argue that it is Zope3-ified. The reason they are strings is that I 
wanted them to be arbitrary (so that if you have a specific use case 
that requires a new kind of category beyond 'user', 'group', 
'contenttype' and 'context', the current set, you can just add it in). 
More specifically, they are keys in a container, and container keys must 
be strings. Having portlets managed inside a containerish API made it 
much simpler to work with them (for example in traversal adapters).

I'll also note that many of the design decisions that went into 
plone.portlets were invented or refined by Philipp von Weitershausen 
(philiKON) who spent a lot of time with me, helping me understand how 
not to re-invent parts of Zope 3. For example, the use of an 
IOrderedContainer as the main portlet mapping was his and Kapil's.

I'd welcome suggestions for improvement. However, hopefully the various 
adapter abstractions in place should mean that even if we want to make 
some of those at a later stage, we won't be prevented from doing so.

What remains in the bundle now, btw is basically

  - UI polish
  - More portlets

Geir has promised to help with these as well, and I'll be getting back 
to it soon.

Cheers,
Martin





More information about the Framework-Team mailing list