Damjan wrote: > .passive(...)? Good idea, active and passive routes are easy to explain. "Active" means participates in matching; "passive" means the route does nothing unless you invoke it for generation.
Should we change .connect to .active or is that too radical? On Jan 17, 2008 2:19 AM, Andrew Smart <[EMAIL PROTECTED]> wrote: > > But 'url' for as an attribute can be shortened to 'url' or > > '.__call__'. The latter is closer to our original plan, > > which would result in: > > > > url_for['google']() > > url_for['google'](q='My Query") > > > > I don't think that you need the () calling if no parameters > must be provided. url_for could do that implicitly - in my > understanding url_for is not a synonym for the mapper class. > I'm currently not so deep in the source, if I'm wrong just > forget my idea. url_for is currently a function that does several other things in addition to generating the route. E.g., adding the application prefix, doing route memory. It calls m.generate() to do the generation. I'm investigating whether it would be feasable to make 'm' and 'url_for' the same object... but it would mean putting all this extra stuff into 'm' that I'm not sure if it belongs there. > But: without the implicit calling (or any other simple > variant) we'll get lots of complaints and questions like > > "I used url_for["google"] and no url gets created, I get a > error message XYZ in my templates" because the people forget > to add the ()... It will return a function object, which will raise an error down the road or put an invalid URL in the hyperlink. I don't think it's possible to have optional (). The .__getitem__ must return a function in order for (**params) to work. It can't tell whether () follow the expression or should follow it -- it's perfectly correct to hold a function object in a variable and call it later. Ben Bangert wrote: > > - url_for can raise KeyError for an unknown named route > That definitely makes it easier to troubleshoot as well, plus people can use .keys() to see all their named routes, which will help out when using map.resource and anything else that someone comes up with that dynamically creates routes. I wasn't planning to support the other dict methods, but maybe we could. If we just say that url_for.routes is a dict of routes by name (as I was planning to implement), that would do the same. Otherwise if we offered .items(), what would the values be? -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" 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-devel?hl=en -~----------~----~----~----~------~----~------~--~---
