Re: [Framework-Team] Re: Review on PLIP #118: Portlets engine based on PlonePortlets and Viewlets
Rocky Burt wrote: On Sat, 2006-23-09 at 22:10 +0100, Martin Aspeli wrote: #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. I didn't really specify here in my goal but I was describing complication in usage and in implementation. It took me quite a while longer to understand what goes where and what adapter uses this (this complication tends to be a known aspect of zope3) with the plip. Compare that with "make a zpt called portlet_fetcher that checks the properties and loads appropriate macros" and it seems a lot more complicated. Of course I'm well aware of the fact that the previous approach wasn't testable all that jazz so I do understand the virtue in the new approach. So in my mind this was a necessary complication. Oh, sure - yes. Hopefully, the README.txt in the plone.portlets package (which is pure Zope 3) will explain how things fit together, but I completely understand that there are more moving parts now to consider. However, the average Plone developer/integrator will never see any of that. For us maintaining it, it's at least well-tested and documented through interfaces and READMEs. Being familiar with how content providers and viewlets work also helps. One of the things I did discover during this work was that the portlets use case is actually more complex than I first thought. Anything I do can help clarify, please let me know. :) Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Review on PLIP #118: Portlets engine based on PlonePortlets and Viewlets
On Sat, 2006-23-09 at 22:10 +0100, Martin Aspeli wrote: > > #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. I didn't really specify here in my goal but I was describing complication in usage and in implementation. It took me quite a while longer to understand what goes where and what adapter uses this (this complication tends to be a known aspect of zope3) with the plip. Compare that with "make a zpt called portlet_fetcher that checks the properties and loads appropriate macros" and it seems a lot more complicated. Of course I'm well aware of the fact that the previous approach wasn't testable all that jazz so I do understand the virtue in the new approach. So in my mind this was a necessary complication. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net 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
[Framework-Team] Re: Review on PLIP #118: Portlets engine based on PlonePortlets and Viewlets
Hanno Schlichting wrote: In this case I would love to see a short tutorial on how to write a new simple portlet in the Plone developer reference. I most definitely intend to make one if/when this is adopted. Having a simple example people can copy as a base for their own products would help quite a lot, as most of the used technologies are not used in the wild that much. If you have the boilerplate ready it's far easier to build on top of that instead of having to reinvent it from scratch. Yep. And I know Martin can write extremely easy to understand and helpful tutorials ;) Thanks ;-) Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Review on PLIP #118: Portlets engine based on PlonePortlets and Viewlets
Hi. Martin Aspeli wrote: > >> #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. In this case I would love to see a short tutorial on how to write a new simple portlet in the Plone developer reference. Having a simple example people can copy as a base for their own products would help quite a lot, as most of the used technologies are not used in the wild that much. If you have the boilerplate ready it's far easier to build on top of that instead of having to reinvent it from scratch. And I know Martin can write extremely easy to understand and helpful tutorials ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Review on PLIP #118: Portlets engine based on PlonePortlets and Viewlets
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 qua
