Mike, first of all thanks for the time you spend helping me.
The reason I defenitively need to use query params is the code does NOT know the name of the table NOR the name AND number of it's primary keys, may be them one or two (or more), needed to locate a single record. I have a dozen of tables in my db and still adding and also dropping some, I don't want to create routes every time. About: > the fewer things in the query string, the better as I said it's a login protected administrative tool so no security problems. > You can use it in the way you're doing, but you'll have to use > ``update_params()`` for any problematic query params. Ok, I'll do it. Thanks again Cheers neurino On Dec 17, 10:21 pm, Mike Orr <[email protected]> wrote: > On Fri, Dec 17, 2010 at 12:04 PM, neurino <[email protected]> wrote: > > I don't need it in routes but in templates to build a link. > > ``url`` is an instance of routes.util.URLGenerator . Its purpose is to > generate URLs based on the routes you've defined. Nowadays it's better > to name your routes and generate them by name [e.g., > ``url("myroutename", arg1="value1")``] rather than using variables to > look up the route [``url(controller="mycontroller", > action="myaction")]. The latter can sometimes choose the wrong route, > which generates to the wrong URL. But you'd still have the variable > collision problem ('action') even with named routes. > > > I wonder just how can I have the url I posted without doing it by > > myself (not a hassle tho) > > To understand what's going on, I'd need to know which route is being > selected for the generation. Are you using the generic > "/{controller}/{action}" and "/{controller}|/{action}/{id}" routes? If > so, the former is chosen for all ``url(controller=, action=)`` calls > and the latter is chosen for all ``url(controller=, action=, id=)`` > calls. That would be the reason 'id' is misbehaving. You can comment > out that route if you're not otherwise using it. And as I said above, > it's better to name your routes and to generate them by name. > > > It would be pretty smart for pylons.url to accept a dictionary as an > > argument for extra request params, jQuery works this way and I never > > had any trouble, rather than using "surplus" kwargs that obviously put > > limits on the keys I can use. > > The Routes API was defined several years ago and is showing its age. > It was borrowed from Rails and assumes that the fewer things in the > query string, the better. Adding another feature to it would just be > more bloat, and I've shown that ``update_params()`` can add any query > params you desire. > > > > > > > To better understand what I need, my real script works this way: > > > it's an administrative tool: > > > a page shows a bunch of selected tables with their records and an > > "edit" link for each row like this: > > >http://127.0.0.1:5000/controlpanel/edit?tName=products&id=1&id_seller=3 > > > then the "edit" action reads table name and values for primary keys in > > querystring then loads that record and creates a form to let user edit > > its contents. > > > Working this way no matter what kind of tables I add to my db I can > > edit its records. > > > I never used, until today a plain "id" for a column name (rather than > > "prod_id") and I could keep on living without it but I wonder why such > > limitation, I mean, haven't you ere seen a page with a ?id=nnn in its > > url?... > > The Routes "way" is to move some of those IDs to the URL path. > > /controlpanel/products/{id}/{action}?id_seller=3 > /controlpanel/{action}/{name}/{id}?id_seller=3 > /controlpanel/{action}/{name}/{product_id}/seller/{seller_id} > > I don't know which one makes the most sense for your application. > Putting the product first focuses on the product, and the action is > just one action among many, and "/controlpanel/producs" is an natural > URL for an index of all products. That would make sense for a > product-centered application. > > But if you want to emphasize the action, and the name "products" is > just one name among many, then you may prefer the action first. > > I'm not sure how 'seller_id' fits into the hierarchy or if it's just > an extra piece of information, so I've left it as a query param. A > seller-centric application might use: > > /controlpanel/{seller_id}/{action}/{name}/{id} > /{seller_id}/controlpanel/{action}/{name}/{id} > > All these are just suggestions based on my philosophy of URL design, > which is that every URL component should contain the one on its right, > and IDs should be in the URL path if they are part of a natural > hierarchy. Routes and ``url`` designed that way too. You can use it in > the way you're doing, but you'll have to use ``update_params()`` for > any problematic query params. > > Also note that if you use ``url.current()`` to generate a URL based on > the current URL, and the current URL has query params, it will NOT > automatically propagate the params to the new URL; you'd have to > re-add them explicitly. That's another reason Pylons users tend to put > IDs into the URL path if feasable, especially if they're using > Paginate. > > -- > 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.
