sloecode-dev team mailing list archive

[Thomi Richards <thomir@xxxxxxxxx>]

Hi,

On 2 June 2011 17:00, Guy K. Kloss <guy.kloss@xxxxxxxxx> wrote:
> For someone who knows this web framework: probably.
>

Good Point.

> That seems to be the only one that uses form submission, as far as my
> recursive grepping has revealed.
>
> Beyond that, there are (potentially) some more that might need fixing:
>

I'm rearranging your items to categorise them:

> * Links to style sheets/JavaScript in lines 10-15:
>  sloecode/templates/base.html
>
> * Image links:
>  sloecode/templates/person-details.html (line 46)
>  sloecode/templates/project-details.html (line 35)

These are a special case because they're requesting static items
(i.e.- things served from our filesystem). They all make use of
functions from the 'helper' module (that's what the 'h' is) to print
out the actual HTML text. That module is sloecode/lib/helpers.py. I've
already patched the link_to function for some other functionality I
needed. Perhaps we should patch all the functions that require a path
to something to take a custom root part? Off the top of my head this
could require patching: image, link_to, help_link, stylesheet_link,
javascript_link and form.

>
> * Links to personal pages in line 31:
>  sloecode/templates/admin/person-list.html
>
> * Link to help:
>  sloecode/templates/admin/person-create.html (line 19)
>  sloecode/templates/admin/person-update.html (line 60)
>  sloecode/templates/person-details.html (line 40)
>
> * As mentioned before:
>  sloecode/templates/login.html (line 18)
>  (don't know whether also needed for the hidden field in line 32)
>
> * Link to login in line 16:
>  sloecode/templates/index.html
>
> * Link to project details:
>  sloecode/templates/project-details.html (line 59)
>

These are all jobs for url_for. So here's how this works:

Check out sloecode/config/routing.py - in this file we configure how
routes maps from URLs to controllers, actions, and parameters. The
default rules are these lines (towards the end):

map.connect('/{controller}/{action}')
map.connect('/{controller}/{action}/{id}')

which means that a url of "/foo/bar" will cause controller
"FooController" to execute action "bar". Similarly, if the URL is
"/foo/bar/123" then the same action will be run, but this time it will
be passed a parameter 'id' with the value '123' [1]. Higher up from
these default rules we have a few special cases, like mapping '/p' to
the project controller, '/u' to the person controller, and '/a/*'
controllers to the admin controllers (please ignore those few lines,
they're fugly).

So 'url_for' reads this map, and takes the arguments you pass to it
and produces a suitable URL. So, to fix the link below:

>> {{ h.form('/auth/dologin', name="login_form") }}

you need to first work out which controller it is, and what the action
name is. In this case, it's:

controller="auth", action="dologin"

so you'd replace it like this:

{{ h.form(url_for(controller="auth", action="dologin"), name="login_form") }}

...that's a simple example. Some actions take additional parameters,
like all the methods for the project controller - they need a
'project_name' parameter, so you'd just do this:

{{ h.form(url_for(controller="project", action="index",
project_name="some_project"), name="login_form") }}

...of course if this were a *real* example then I'd use the real
project name, which would be available to the template in a variable
already.


Here are a few more tips to help you out:

from the sloecode root directory, if you type 'paster shell' then you
get a python shell (or ipython, if you have it installed) with the
WSGI app loaded correctly already for you, so you can do something
like this:

>>> import sloecode.lib.helpers as h
>>> h.url_for(controller='project', action='index', project_name='sloecode')
'/p/sloecode/index'

Then compare the output with the old hard-coded path you're about to replace.

> If one tells me how to do it, I'll put it into my branch and propose a merge
> :)

Done :)


Let me know if you need a hand.

Cheers,

[1] Okay, so it's actually more complicated than that - pylons does
method introspection, so actions can actually take fewer or more
parameters than that, which just causes no end of confusion.