[Product-Developers] Re: [Plone-developers] plone.app.layout ViewletBase and portal_url

[Wichert Akkerman]

Previously Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
> > Wichert Akkerman wrote:
> > > I'm debugging some code that broke in a very unexpected way:
> > > 
> > > (Pdb) p getToolByName(self, 'portal_url')
> > > 'http://localhost:8080/Plone'
> > > 
> > > That should return a tool, not a string. This turned out to be caused by 
> > > plone.app.layout.viewlets.common.ViewletBase.update which sets 
> > > self.portal_url to the portal URL. This looks harmless, but due to 
> > > acquisition this will break patterns like this:
> > > 
> > > class MyViewlet(ViewletBase):
> > >    def update(self):
> > >       super(MyViewlet, self).update()
> > >       self.mt=getToolByName(self.context, "portal_membership")
> > >       self.somemethod()
> > > 
> > >    def somemethod(self):
> > >       return self.mt.ToolMethod()
> > > 
> > > the problem here is that in somemethod() self.mt gets acquisition wrapped in 
> > > the viewlet, so when ToolMethod does getToolByName(self, "portal_url") it
> > > finds the portal_url variable ViewletBase.update set on the viewlet instead
> > > of the tool.
> > 
> > Ouch!
> > 
> > This is precisely the reason that I *always* do (and advocate):
> > 
> >      context = aq_inner(self.context)
> > 
> > at the top of any method in a view or viewlet, and then use the 
> > 'context' variable throughout the method instead of self.context.
> 
> That would still have broken: self.mt will give you the membership tool
> wrapped in the view, so a getToolByName call inside the membership tool
> would get the wrong result.
> 
> > > I would like to rename that variable in ViewletBase to prevent this problem 
> > > but I do not have a good overview of how many people are relying on that 
> > > specific variable to be set. If you are relying on this please let me know 
> > > ASAP. If I here no objection I intend to rename the variable for the 
> > > upcoming Plone 3.1 alpha release.
> > 
> > I'm not sure we can do this. It's used in templates (view/portal_url) 
> > that are likely to have been customised in several places. :-/
> 
> Hmm. Perhaps we can add a zope.deprecate wrapped portal_url in
> ViewletBase to warn people?

That was doable, so I did that. The upside of that is that customized
tempaltes still work. The downside is that derived classes assigning to
self.portal_url now break. I'm not sure if that's really better,
hopefully the results from integrator testing will tell us.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.