[Grok-dev] Re: Computing URLs relative to the application
Philipp von Weitershausen
philipp at weitershausen.de
Mon Apr 9 06:45:48 EDT 2007
> On Apr 5, 4:18 am, Philipp von Weitershausen
> <phil... at weitershausen.de> wrote:
>> Martin Aspeli wrote:
>>> Sure. But there should be some common mechanism in Grok for this (the
>>> common view base class is probably fine) so that each view doesn't need
>>> to define it for itself!
>> Yup, that mechanism is called subclassing :)
> I gotta say I find subclassing just to inherit convenient
> functionality quite evil. I'd prefer to use a view lookup or some
> random utility method. Of course this is just my particular taste --
> also being burned a few times with people saying, "oh, I need feature
> X, I'll just inherit from X's mixin class".
- We're not introducing a mixin class, it will be part of the standard
grok.View base class. We *require* you to inherit from that anyway
(unless you absolutely want your own base class in which case you're
free to do so, but need to take care of grokking it yourself).
- I personally don't see much of a use case for wanting to customize
whatever view/application_url returns, but perhaps you do (if so,
please share it with us). Note that it'll use standard machinery like
zope.traversing.api.getParent() to get an object's parent and
zope.traversing.browser.absoluteURL() to compute the application
object's URL, once found. Both functions work through adapters which
- And yes, convenience *is* the main and only factor here. It's already
possible to compute the application object's URL, but it's tedious to
spell it out. In such cases, putting the implementation into a base
class is a valid procedure (sharing an implemetation).
Note that you won't have to use view/application_url if you don't like it :)
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev