Custom Portlet Manager in a Viewlet
|
|
Jason Lantz
|
Apologies in advance for the long post, but I promise to write a How
To on plone.org once I figure this out as I'm sure it would be useful to lots of Plone developers and integrators. I have been working on building custom portlet managers for a few sites over the last week. I've been using the following two sources of information in addition to the code: http://plone.org/documentation/how-to/adding-portlet-managers/view The problem with this document is it makes you build a different management view for your portlet manager instead of using the default @@manage-portlets view provided by Plone. In one site I'm working on, there are 3-4 custom portlet managers. I would prefer, from a UI perspective, to allow the user to place all portlets via one page. It seems confusing to the user to have 4-5 different pages to manage portlets for a single piece of content. Plus, the management portion of the page doesn't show up where the portlets show up (they show up in the body), which is even more confusing. http://svn.plone.org/svn/collective/plonetheme.pizza/branches/footer-portlets-experimentation/ This branch seems to work to add portlet a custom portlet manager and have its management view displayed in place in the @@manage-portlets view, pretty cool. This branch is the basis for the implementation I'm working on. However, I ran into a pretty major snag... When trying to do more than just add portlets to the new manager (i.e. move or delete portlets), the kss actions are failing complaining that no kss attribute "viewname" was passed. I traced this down to the edit-manager-macros.pt template in plone.app.portlets which adds the kss attribute viewname using the following TAL expression: "class string:kssattr-viewname-${view/__parent__/__name__}" This seems to work just fine for the left and right column portlet managers, but they are placed in the main_template directly instead of being placed as viewlets which I would prefer for a number of reasons, namely that I need to place portlet managers in plone.top, plone.abovecontent, and plone.footer. When the portlet manager is rendered via a viewlet, the resulting kss attribute is kssattr-viewname- which is the cause of kss not being able to set the viewname attribute when calling the kss commands in plone.app.portlets. I dug into the code more and discovered the ManagePortletsViewlet class (and associated subclasses) in browser.manage of plone.app.portlets. The docstring seems to indicate this class was created specifically to fix the problem I'm encountering. The pizza theme branch I'm basing my code off of does use this class in the zcml, but it's not resolving the problem. I have searched and searched and found no other products using this class or its subclasses (other than the pizza theme branch linked above). I also verified that the pizza theme branch has the same issue as the code I'm working on. A second issue I ran into with the viewlet based portlet manager is that it fails to render altogether when placed inside a viewlet manager inside a viewlet manager. The best example I can think of is trying to add a portlet manager inside of plone.header which is inside of plone.top. As I can somewhat hack my way around this problem using some fun css and placing the portlet manager in plone.top, I haven't spent much time on it but would love any ideas/input. Thanks for making it this far through the post. Any input would be greatly appreciated. - Jason Lantz (aka babel in irc) ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plone-Users mailing list Plone-Users@... https://lists.sourceforge.net/lists/listinfo/plone-users |
|||||||||||||||
Martin Aspeli
|
That'd be nice! It should be possible to re-use the existing view. Basically, there is a specific portlet manager renderer that renders the admin GUI, and this is registered for the IManagePortletsView marker interface. The idea is that it should "just work" if you have additional portlet managers in main_template. I was going to point you to this branch. :) Basically, the problem is that the portlet manager renderer adapter factory (the one that finds the appropriate view) ends up thinking the *viewlet* is the 'view' where the portlet manager is shown, not the ultimate parent view. This may or may not be right, depending on what you expect. :) I suspect this is happening because the bit of integration code in the branch you found that attempts to trick the portlet manager into thinking it's being rendered on the @@manage-portlets view directly (rather than in a viewlet) is old, and doesn't know about recent changes to the standard edit view. Right. The problem here is that view/__parent__ is going to be the viewlet, not the ultimate view. That makes sense. Indeed. I did it whilst sitting next to David working on the pizza theme. :) Sounds like we need to override that variable or make it more dynamic somehow. Where is it defined? In the view or in the portlet manager renderer or? Right - it's probably just doing one "parent" check, not a loop. I don't have time to dig into this too deeply, but you are definitely on the right path. Let me know if you get any further. :) Martin |
|||||||||||||||
|
Jason Lantz
|
Martin,
Thanks for the response... I had a feeling I'd find the author of that docstring somewhere on this list. Please see comments below... On Wed, Jul 23, 2008 at 1:48 PM, Martin Aspeli <optilude@...> wrote: > It should be possible to re-use the existing view. Basically, there is a > specific portlet manager renderer that renders the admin GUI, and this is > registered for the IManagePortletsView marker interface. The idea is that it > should "just work" if you have additional portlet managers in main_template. > Yep, that's exactly my plan :) >> http://svn.plone.org/svn/collective/plonetheme.pizza/branches/footer-portlets-experimentation/ >> This branch seems to work to add portlet a custom portlet manager and >> have its management view displayed in place in the @@manage-portlets >> view, pretty cool. This branch is the basis for the implementation >> I'm working on. However, I ran into a pretty major snag... >> > > I was going to point you to this branch. :) Basically, the problem is that > the portlet manager renderer adapter factory (the one that finds the > appropriate view) ends up thinking the *viewlet* is the 'view' where the > portlet manager is shown, not the ultimate parent view. This may or may not > be right, depending on what you expect. :) > I honestly have no expectations, but unfortunately, the edit-portlets-macros.pt file does. My only expectation is to get it working. >> This seems to work just fine for the left and right column portlet >> managers, but they are placed in the main_template directly instead of >> being placed as viewlets which I would prefer for a number of reasons, >> namely that I need to place portlet managers in plone.top, >> plone.abovecontent, and plone.footer. When the portlet manager is >> rendered via a viewlet, the resulting kss attribute is >> kssattr-viewname- which is the cause of kss not being able to set >> the viewname attribute when calling the kss commands in >> plone.app.portlets. >> > > That makes sense. > > > >> I dug into the code more and discovered the ManagePortletsViewlet >> class (and associated subclasses) in browser.manage of >> plone.app.portlets. The docstring seems to indicate this class was >> created specifically to fix the problem I'm encountering. >> > > Indeed. I did it whilst sitting next to David working on the pizza theme. :) > > > >> The pizza theme branch I'm basing my code off of does use this class in >> the >> zcml, but it's not resolving the problem. I have searched and >> searched and found no other products using this class or its >> subclasses (other than the pizza theme branch linked above). I also >> verified that the pizza theme branch has the same issue as the code >> I'm working on. >> > > Sounds like we need to override that variable or make it more dynamic > somehow. Where is it defined? In the view or in the portlet manager renderer > or? > I'm a little confused about what "it" is, but I'm assuming you mean view.__parent__ In that case, this is the crux of my problem at the moment. I'm still getting my head fully wrapped around zope3 and this one goes through enough levels that I'm getting lost. I'm getting very confused about the difference between an edit manager renderer versus the manager and how these classes are used by the portlets engine. I think I've got a ~50% understanding, but that's not cutting it :( I know that __parent__ on the view gets passed in __init__ as the "view" argument in the classes in browser.editmanager and in the ManagePortletsViewlet class you created in browser.manager. It seems most of the normal classes are setting this in the edit manager. Your class seems to be the only one in browser.manage that does this. I'm wondering if it's possible I need something like EditPortletManagerRendererViewlet? Another thing that has me confused is if view.__parent__ points to a viewlet, shouldn't view.__parent__.__name__ return the zcml registered name of the viewlet? If this is the case, why would the kss attribute be blank? Another option... would it be possible to have __init__ on the edit manager check if the view argument passed to it was in fact a view instead of a viewlet. If it were a viewlet, keep going up through the parent until you find a view? Thanks, Jason Lantz ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plone-Users mailing list Plone-Users@... https://lists.sourceforge.net/lists/listinfo/plone-users |
|||||||||||||||
Martin Aspeli-2
|
Hi Jason,
>>> The pizza theme branch I'm basing my code off of does use this class in >>> the >>> zcml, but it's not resolving the problem. I have searched and >>> searched and found no other products using this class or its >>> subclasses (other than the pizza theme branch linked above). I also >>> verified that the pizza theme branch has the same issue as the code >>> I'm working on. >>> >> Sounds like we need to override that variable or make it more dynamic >> somehow. Where is it defined? In the view or in the portlet manager renderer >> or? >> > > I'm a little confused about what "it" is, but I'm assuming you mean > view.__parent__ No, I mean the kssattr "variable". It needs to be set the view name, I presume. I can't recall how or where it gets set, but it probably needs to use something more clever than string:${view/__parent__/name} or at least allow some kind of override so that you can tell it the right view name (which should probably be 'manage-portlets' in this case). Is this from the portlet manager renderer template? or the @@manage-portlets view template? Or something else? > In that case, this is the crux of my problem at the > moment. I'm still getting my head fully wrapped around zope3 and this > one goes through enough levels that I'm getting lost. The @@manage-portlets view and the interaction with the "edit mode" portlet managers is unfortunately fairly tricky precisely because it tries to be generic enough to support different types of portlets across different portlet managers. :-/ > I'm getting > very confused about the difference between an edit manager renderer > versus the manager and how these classes are used by the portlets > engine. I think I've got a ~50% understanding, but that's not cutting > it :( Okay, so the portlet manager is just the storage. It's basically just a utility that lets you get hold of portlet assignments. You can get hold of a portlet manager renderer (think, the view(let) of the portlet manager). The default one just renders all the portlets. The "edit" one renders the editing GUI. It's like a view override. The "edit" renderer is registered such that it is preferred over the standard one when you are on the @@manage-portlets view (or another view implementing a particular interface). Does that help? Also see http://martinaspeli.net/articles/an-introduction-to-plone-portlets. > I know that __parent__ on the view gets passed in __init__ as the > "view" argument in the classes in browser.editmanager and in the > ManagePortletsViewlet class you created in browser.manager. It seems > most of the normal classes are setting this in the edit manager. Your > class seems to be the only one in browser.manage that does this. I'm > wondering if it's possible I need something like > EditPortletManagerRendererViewlet? I'm not quite sure what you mean. I think the easiest thing would be to just fix the template where that kssattr thing is being set so that it makes a less naive assumption about where to get the view name from. > Another thing that has me confused is if view.__parent__ points to a > viewlet, shouldn't view.__parent__.__name__ return the zcml registered > name of the viewlet? If this is the case, why would the kss attribute > be blank? I'm not sure if viewlets work this way, i.e. if they get a __name__ like that. I think your understanding is right, though - they probably should. > Another option... would it be possible to have __init__ on the edit > manager check if the view argument passed to it was in fact a view > instead of a viewlet. If it were a viewlet, keep going up through the > parent until you find a view? Yes, it could do that. Another option, possibly a better one, would be to still store __parent__ as before, but to also find the "ultimate" view by walking up the __parent__ chain and store this as e.g. self.real_view or some such. The kssattr thing would then be set using this, rather than view/__parent__. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plone-Users mailing list Plone-Users@... https://lists.sourceforge.net/lists/listinfo/plone-users |
|||||||||||||||
| Free Forum Powered by Nabble | Forum Help |