← Back to team overview

sloecode-dev team mailing list archive

Re: configurable root path of sloecode instance

 

Hi,

On 31 May 2011 18:57, Guy K. Kloss <guy.kloss@xxxxxxxxx> wrote:
> In my case, I have now been able to access sloecode through Apache's
> mod_proxy, but that does not work with content generated by sloecode that
> inserts paths into the content of web pages, e. g. links, targets for POST/GET
> in forms, ...
>

There are two issues with this. One of them is easy to solve, and one
requires a bit of typing (but not thinking so much):

First, since we're using python-routes to map URLs to controllers we
can easily change the root path of the sloecode instance. All that
would be required is a change to the routes configuration - it
shouldn't be hard to put this in the config file, so it can be easily
changed. That's the easy part.

The hard part is that in some places we've been a bit...sloppy with
our template code: we've hard coded URL paths in many places, instead
of using the url_for method. An example of it done correctly is:

sloecode/templates/project-manage-users.html:13 where we have the following:
{{ h.form( h.url_for(controller='/project', project_name =
project_name, action='process_manage_users') ) }}

This form action uses a URL path generated by 'url_for', which
resolves the controller name, action name, and parameters to a URL
path by looking at the python-routes mapper and returning the correct
string. However, in some places, such as:

sloecode/templates/login.html:18 we have a hard-coded path:
{{ h.form('/auth/dologin', name="login_form") }}

There's an existing bug report for this:

https://bugs.launchpad.net/sloecode/+bug/700202

I have spent some time in the past converting all the admin templates,
so those should work (unless hard-coded paths have snuck back in
again). This is the kind of job that can be done incrementally, and is
pretty easy to code & verify that you've done the right thing (what
I'm trying to say here is "merge proposals are most welcome" :P).

Finally, it'd be super cool if we could hook up the pylons functional
unit tests to test for this kind of thing - it should be pretty easy
to iterate over all the controller actions and verify that when we
move the root path the actions are still accessible at the new path.

Anyway, it's one of those things that I'll probably get around to
squashing one afternoon when I just want to get something completed.
These days it seems like I'm struggling with debian packaging and not
writing much code at all.


Cheers,


Follow ups

References