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