[Grok-dev] Re: Cancel button in forms

[Martijn Faassen]

Brandon Craig Rhodes wrote:
> Martijn Faassen <faassen at startifact.com> writes:
> 
>> You need to explain how this will actually help the writer and the
>> reader of code that deals with redirects significantly enough to be
>> worth having another way of doing things.
> 
> Maybe I made the mistake of thinking everyone's Grok code looks like
> mine. :-) Glancing over my Grok applications, there is only one place
> where self.redirect() doesn't have self.url() inside of it, which is
> when I'm directing someone off-site.  So this would very much help me,
> at least, Not Repeat Myself. :-)


More explanation of the underlying philosophy of your proposal won't 
work if you don't demonstrate your proposal. You really need to show 
some code samples. I believe you when you say most self.redirect calls 
get a self.url input; it'll be the same for most people, I expect. I'm 
happy to consider an improvement. But so far you haven't shown how your 
new proposal is better, by example. I don't actually understand your 
proposal fully yet as a result.

> And I'm not sure what you mean by a different way of doing things.
> Since a redirect, by its very definition, goes to a URL, it seems
> obvious that whatever you pass to self.redirect(), whether string or
> object or method, is going to be used by redirect() in some sort of
> attempt to create a URL.  So you're doing what you always do: passing
> to redirect() "the place you want to go" with the redirect.  

URL construction typically uses more than just an object:

* the object to create the URL to

* the view on the object or the name of the sub-object

* possibly URL parameters you want to add

Assuming self.redirect will try to make an URL out of things, passing in 
just an object to self.redirect will only be enough in some of the cases.

>> You could do self.redirect(obj)' in some cases if self.redirect
>> tried to adapt to IAbsoluteURL, but only if you're not redirecting
>> to a view on that object or don't want to pass in URL paramters.
> 
> Are you claiming that a View cannot be adapted to IAbsoluteURL, or are
> you pointing out that the resulting URL is really, really ugly and not
> one that should ever, under any circumstances, be displayed to the
> user? :-)

No, you could indeed pass a view into IAbsoluteURL, I imagine ,that's a 
good point. But show me the more succinct code where a view is being 
passed into self.redirect, please. Include the bit where you *obtain* 
the view. Compare and contrast to the current approach.

> Why would URL parameters be forbidden?  Couldn't they still be encoded
> in the dictionary passed as the second argument?  I don't see any
> reason for disallowing this...

I don't understand. Are you suggesting we allow the same arguments to 
self.redirect() as we do for self.url() or not? I thought you were 
talking about using adaptation on the single argument, so that it 
doesn't allow only strings.

>> Code that produces URLs might also become a bit harder to recognize;
>> we'll have more than one ways to do things.
> 
> The code that produces URLs would stay exactly where it is: in a bunch
> of adapters in zope.traversal.browser.absolute_url, where it's always
> lived. :-) And having that magic kick off when someone writes
> "self.redirect(some_object)" will be just about as opaque to the
> end-programmer as having it kick off when he writes, more laboriously,
> "self.redirect(self.url(some_object))". :-)

So are you suggesting we can do this?

self.redirect(obj)

self.redirect("foo")

self.redirect(obj, "foo")

self.redirect(obj, "foo", data={'parameter': 'one'})

exactly like we do this right now?

self.url(obj)

self.url("foo")

self.url(obj, "foo")

self.url(obj, "foo", data={'parameter': 'one'})

or not? If not, how do you suggest people write anything beyond the 
first example? Give details please, including the code that actually 
obtains the correct view and code that actually passes in a data 
dictionary (which is a new convenience on the trunk).

If you *do* want self.redirect to take these arguments, my objections to 
carrying over the magic arguments of self.url to self.redirect were 
stated previously - I'd rather not start spreading these parameters 
around. This set of arguments was made to be rather magic (deliberately, 
for convenience)  and I'd prefer to have them in one place. When a set 
of arguments is repeated like this, it also feels like we can instead 
construct an object and pass that, and we do - the URL string. Perhaps 
you can find good counter arguments to these objections, or make clear 
that the increased convenience outweighs the risk. Please let us know.

Regards,

Martijn