[Grok-dev] Re: Computing URLs relative to the application

[Philipp von Weitershausen]

Rocky wrote:
> 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
   are customizable.

- 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