Hi, Marc-Aurèle I agree that there is no care about context_obj in this view and that your solution b) is better A few options, thinking aloud, mostly
There is already a hack on traversal to allow for the current URL: .../rss_2_0/actu-racketiciel.rss, since the name of the view is "rss_2_0" This is done by the view's __getitem__, whose current effect is simply to ignore URL segments after rss_2_0 You may build on that to find the context_obj with the scheme you suggest. The problems I can foresee: a) traversal start. In pure Zope 2 logic, this should be acquisition from the portlet (a1), but you may want to start with the container (a2) or the portal himself (a3), that's a matter of convention, as long as it is clear. b) either you (b1) always discard the last segment (because it'll always be the file name) and that's not so easy with this __getitem__ unless you store the segments on the view and actually use them from initFolder (discarding the last one) OR (b2) you maintain compatibility with hypothetical instances that don't have such last segment and discard it only if it does not match an existing object I tend to favor a3 and b1. A totally different approach would be to have the traversal *from the portlet* return self and construct a path to context_obj in request through a __getitem__ on the portlet, and don't touch the view besides reading it from request. This has the advantage to be applicable to any type of portlet that may need a context_obj in a view, but is more dangerous, because you'll have to also support ordinary traversals to, e.g, images in the portlet object. The corresponding URL would be slightly different : http://non.aux.racketiciels.info/.cps_portlets/actu-racketiciel/sections/gdt/racketiciel-info/rss_2_0/actu-racketiciel.rss Don't know if the view lookup would still work, but can't see why it shouldn't Cheers On Thu 6/10/11 15:34 , "M.-A. DARCHE" wrote:: Hello, The new Five/Zope3 views ".browser.exportviews" that ContentPortlet now uses has caused a regression for the search_type == 'related' option of ContentPortlet. To be more precise: In CPSPortlets/skins/cpsportlets_widgets/getContentItems.py there is a case for search_type == 'related' that tries to get the Subject of the "context object". When in a web page, when CPSPortlets/skins/cpsportlets_widgets/widget_portlet_content.pt calls getContentItems.py, the "context object" is the container in which the web page rendering the portlet resides. But with the new Five/Zope3 views for the exports the portlet is not accessed within a folder container, but directly from the portlet container. For example this portlet is accessed directly http://non.aux.racketiciels.info/.cps_portlets/actu-racketiciel/rss_2_0/actu-racketiciel.rss and there isn't any knowledge passed that this portlet export is done from http://non.aux.racketiciels.info/ To fix this I can think of two solutions: a) Pass an "rpath" argument to the portlet view, something like: http://non.aux.racketiciels.info/.cps_portlets/actu-racketiciel/rss_2_0/actu-racketiciel.rss?container_rpath=sections/gdt/racketiciel-info But that doesn't look really good. b) Craft the URL of the Five view like href string:${ptlurl}/${format}/${container_rpath}/${export_name} instead of the actual href string:${ptlurl}/${format}/${export_name} That would give something like http://non.aux.racketiciels.info/.cps_portlets/actu-racketiciel/rss_2_0/sections/gdt/racketiciel-info/actu-racketiciel.rss And this looks a little better. What do you think? Thanks, -- Marc-Aurèle DARCHE http://cps-cms.org/ AFUL http://aful.org/ Association Francophone des Utilisateurs de Logiciels Libres French speaking Libre Software Users' Association _______________________________________________ cps-devel mailing list http://lists.nuxeo.com/mailman/listinfo/cps-devel _______________________________________________ cps-devel mailing list http://lists.nuxeo.com/mailman/listinfo/cps-devel
