[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