Hi all,

First off I have to admit that I welcome any sort of increased
flexibility when it comes to portlets.

I will add the following goals of of any sort of plip to handle this
(loosely based on the motivation factors mentioned in the plip writeup):

  1. Increase ability to customize
  2. Improve control
  3. Improve Plone configuration UI story
  4. Prevent over-complication
  5. Good test coverage

Of course I realize #4 will increase negatively as #2 and #3 increase
positively, so the end net requirement is that a good balance is found.

So, after perusing the plip 118 svn bundle, getting it setup in recent
svn snapshot of Zope 2.10, I was quickly running with a Plone site where
I could start testing the plip 118 functionality.

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.

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.

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.

  #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.

  #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.

  #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.

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.

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.


Regards,
Rocky

-- 
Rocky Burt
ServerZen Software -- http://www.serverzen.com
News About The Server (blog) -- http://www.serverzen.net

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to