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.
