Hi James, On Tue, Jun 5, 2018 at 2:19 PM James Schneider <[email protected]> wrote:
> On Mon, Jun 4, 2018, 12:37 PM Melvyn Sopacua <[email protected]> > wrote: > >> Aha! Now I get it! This should be solveable at the WSGI layer: >> >> >> >> PATH_INFO >> >> The remainder of the request URL's "path", designating the virtual >> "location" of the request's target within the application. This may be >> an empty string, if the request URL targets the application root and does >> not have a trailing slash. >> >> >> >> See https://www.python.org/dev/peps/pep-0333/ >> >> >> >> A URL rewrite or proxy at the webserver level should work as well. It may >> take a bit of experimenting. >> > > Would URL rewrites solve this? How does that affect URL's generated in the > template? > I also don't think this works for the outbound traffic for the html urls. It sounds like a separate 'site' with the sites framework is needed, along > with a modified urls.py that does not include the year and slug in the path. > I don't think I need to do this: assuming the subdomain.sponsor.url resolves correctly to include the required path, this is already taken care of. > Your might be able to use the existing urls.py by making the year and slug > optional in the regex. When using the sponsored site, you would pass along > extra context to the URL dispatcher that includes the year/slug or whatever > data is being assumed by the usage of the sponsor URL. > I think I follow what you're suggesting. However, I think this would require a wholesale redesign of urls.py and I'm not clear I can see how this might work given all the other functions that are already in place. I'll ponder a little more as our urls.py could benefit from a major scrub/refactor. If we could get this to work in the urls.py, then I think we are done. Failing that, I'm now wondering if there is something we can do to call and modify the output of {% url %} and reverse() ourselves? I think there is essentially a worked example in django-hosts ( https://github.com/jazzband/django-hosts). Maybe that these functions are emulated in django-hosts is a hint that urls.py is not the way to go? > Basically, you need two different paths to the same resource, dependent on > the domain name or site in question. > > Why not just leave the year and slug in and save yourself the extra work? > Is the vanity path a requirement or just 'nice to have'? > If we do implement this, the vanity path is a requirement as subdomain.sponsor.url essentially duplicates the /year/slug/ part of the path. There are other parts of our site that we could in future want to associate with other sponsors in a similar manner, so the /year/slug/ must go! Thanks for helping me think this through, -- R. Richard Brockie Real-time bicycle race results - www.ontheday.net -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAKv-vOWO0Q7NS8q%3DkfP2RuwnSK-998fdAynKT3q2Jcae0ODMHg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
