On Fri, Dec 4, 2009 at 2:45 PM, Jonathan Vanasco <[email protected]> wrote: > I'm not going to waste time describing why you should be doing > that. everyone on the internet follows that paradigm for a reason.
Ouch, that sounds like "I'm better than you but I'm not going to tell you why." In other words, it may or may not be true, depending on whatever he might be basing it on. The problem with calling one action from another is that it breaks the one-to-one correspondence between URLs and action. Proxy caches and and search engines depend on this correspondence, otherwise they'd be returning random inappropriate results. However, it's not always bad. @validate calls the form action if the data doesn't validate, rather than redirecting to the form. It could redirect to the form of course, but then it would have to pass all the form data, and the other action would have to be modified to display it in that circumstance, etc In the case of doing login in place, the issue is that proxies and search engines can't log in, so they'd always see the login page and think it was the normal content. Whereas with a redirect, they know that URL is related to the other URL, and if they analyze the site they might think, "Ah, every page on this site goes to a single page." Another factor is that proxies and search engines only cache GET requests with status 200. So if the request is not GET, or the other action changes the status to 401 (Unauthories, or not logged in), then it's safer. In the @validate case, the original request is not GET (usually). As for "transfering to another function", that is exactly what "return self.othermethod(args)" does. Although technically it's a subroutine call, the net effect is the same. Shalisesh Kochhar wrote: > http://jjinux.blogspot.com/2009/11/web-redirecting-user-back-after-some.html Yes, that's the normal way to save the original URL during login, and then redirect back to it afterward. Graham Higgins wrote: > or, if it has to be a controller method, prefix it with an underscore which is Pylons convention for "don't expose this action". Er, it's a convention with some precedence in Python. It's not necessarily a Pylons standard or something you have to do. I go back and forth on whether to underscore all my utility methods. However, if it's a utility method, it's likely useful for more than one controller, and thus would belong in the base controller. You could turn it into a standalone function too. However, I avoid doing that with routines that use the Pylons magic globals or other special features (unless they're passed in as arguments), because it makes it harder to refactor the code to another framework later if you need to. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
