[Grok-dev] grok.url() requiring a request object a bit inconvenient

[Leonardo Rochael Almeida]

Hi Sebastian,

On Fri, Oct 30, 2009 at 14:04, Sebastian Ware <sebastian at urbantalk.se> wrote:
> I find it a bit inconvenient that you have to supply a request object
> with the grok.url() method. If I want to create an url during an event
> to for example send an email, it would be great if I could call...
>
>   grok.url(obj)
>
> ...without having to supply a request object.

The problem is that, with Virtual Hosting, it's not actually possible
to know the URL of an object unless you hardcode the information of
where the "root" of the website is in relation to the "root" of your
application. In Unix-y terms, it's not possible to know beforehand
which "folder" or "object" of your application is "mounted" in which
"folder" of the URL space. A single apache installation could point to
your Grok application from multiple hostnames, foldernames and even
ports.

Only the request object has the proper information of how a browser
request is coming to your application to be able to calculate the
proper url of an object.

If you hardcode this information, you run the risk of it getting out
of sync with your server configuration, whether it's its hostname or
other less obvious URL mapping.

Of course, grok Views, have .url() a method that does not take a
request parameter, since the view itself already has access to the
request, since they are adapters for content and request under the
hood.

Alternatives to requiring a request object including using a
thread-local storage to keep
the information of where the currently running request is coming from.
Variants of this idea include having a thread-local utility registry,
updated at the root traversal, keeping a request utility that could be
fetched by a global grok.url() or, like in Zope2, having a dynamically
generated object wrapping your object so that you could have a url
with a simple method call, like myobj.url().

Neither of these seem to be palatable to the current direction of
development of the Zope community, but I mention them here for
completeness, and so that we don't forget our past :-)

Cheers, Leo