grok.url() requiring a request object a bit inconvenient

[Sebastian Ware]

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.

Mvh Sebastian


_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Leonardo Rochael Almeida]

Hi Sebastian,

On Fri, Oct 30, 2009 at 14:04, Sebastian Ware <sebastian@...> 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
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Sylvain Viollon]

> Hi Sebastian,
>
> On Fri, Oct 30, 2009 at 14:04, Sebastian Ware <sebastian@...>
> 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.
>
> [...]
>
> 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 :-)
>

  You can already get back the request via getInteraction(). As far as I
know.

  You don't need evil hacks like you describe (even it's what may do
getInteraction()).

  So you can make it work easily. (However you need something different on
Zope 2 for five.grok, so the code to get the request needs to be easily
changeable).

  And at some point I need the url function as well, and didn't have, and
the code in grok.View is quite long before calling an utility function,
and I was sad. +1 to have a such method (if it's possible).

  Best regards,

  Sylvain,



_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Jan-Wijbrand Kolman-3]

Sebastian Ware 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.
>
> Mvh Sebastian


-1 for not having to pass a request object to the grok.url() helper
function.

As said in this thread: the request contain crucial information about
how to compute the URL.

+1 for a convenience function to get to the current request object in a
formalized way.

Even though the ZTK does not really promote retrieving the request
object "yourself" (and I think rightfully so!) there are situations
where you really really want to be able to get the request anyway.

Having such a convenience method makes calling grok.url() somewhat easier..:

   grok.url(grok.global_request(), obj)

...but still we maintain grok.url()'s explicitness and testability.

There're a couple of packages out there that do get to the "global"
request. We should look that these packages for inspiration when
implementing grok.global_request(). On the top of my head there is:

* hurry.resource (or is it hurry.zope.resource)

* zope.globalrequest

There're probably more..


Having said this, I have to remark that I only rarely need to get to the
request "myself". To me it seems most often, with the right factoring,
the request is just there in the view-like components.


regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Sylvain Viollon]

On Sun, 01 Nov 2009 15:03:52 +0100
Jan-Wijbrand Kolman <janwijbrand@...> wrote:

  Hello,

> Even though the ZTK does not really promote retrieving the request
> object "yourself" (and I think rightfully so!) there are situations
> where you really really want to be able to get the request anyway.
>

  I fully agree that you should not have any code where you would need
  to retrieve the request, with something like global_request. The
  reason is simple, is that *if* the request is need in your code, it
  should be added as a parameter. Otherwise it's using global variables
  for me.

  It sounds a bit like you want to write generic code, in a library, and
  that at the end, you end up not.

  But anyway, it's possible if you want, and you do not need to
  write some dirty code yourself to do it.

  I am all +1 to have a method:

     grok.url(object, request, **other_options)

  Best regards,

  Sylvain,


--
Sylvain Viollon -- Infrae
t [phone] -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Jan-Wijbrand Kolman-3]

Sylvain Viollon wrote:
>   I am all +1 to have a method:
>
>      grok.url(object, request, **other_options)

This already is the case :)

   http://zope3.pov.lt/trac/browser/grok/trunk/src/grok/__init__.py#L39

regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Sebastian Ware]

And this is an inconvenience because I have to figure out how to get  
the request object, and then repeat that code whenever I use  
gork.url()...

I would rather have

    grok.url(object, request=None, **other_options)

where it gets the request object (like in a view) if I don't provide  
one myself.

Mvh Sebastian

2 nov 2009 kl. 14.25 skrev Jan-Wijbrand Kolman:

> Sylvain Viollon wrote:
>>  I am all +1 to have a method:
>>
>>     grok.url(object, request, **other_options)
>
> This already is the case :)
>
>   http://zope3.pov.lt/trac/browser/grok/trunk/src/grok/__init__.py#L39
>
> regards,
> jw
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> https://mail.zope.org/mailman/listinfo/grok-dev

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Jan-Wijbrand Kolman-3]

Sebastian Ware wrote:
> And this is an inconvenience because I have to figure out how to get  
> the request object, and then repeat that code whenever I use  
> gork.url()...

Not with my previous proposal formalizing the "hack" of retrieving the
request with something like grok.global_request(). This would not
require a change in grok.url() and at the same time retrieving the
request will not force you to repeat code.

regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Sebastian Ware]

2 nov 2009 kl. 21.43 skrev Jan-Wijbrand Kolman:

> Sebastian Ware wrote:
>> And this is an inconvenience because I have to figure out how to get
>> the request object, and then repeat that code whenever I use
>> gork.url()...
>
> Not with my previous proposal formalizing the "hack" of retrieving the
> request with something like grok.global_request(). This would not
> require a change in grok.url() and at the same time retrieving the
> request will not force you to repeat code.
>

You are right, that would be great solution for me!

Mvh Sebastian

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Jan-Wijbrand Kolman wrote:
> There're a couple of packages out there that do get to the "global"
> request. We should look that these packages for inspiration when
> implementing grok.global_request(). On the top of my head there is:
>
> * hurry.resource (or is it hurry.zope.resource)

The latter (hurry.zoperesource), as hurry.resource doesn't know anything
about Zope.

> * zope.globalrequest

I think the simplest thing would be to simply make Grok depend on
zope.globalrequest and import the method to get the global request into
the grok namespace.

I'm +1 on that approach.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev