Hi James, On Tue, Jun 5, 2018 at 2:19 PM James Schneider <jrschneide...@gmail.com> wrote:
> On Mon, Jun 4, 2018, 12:37 PM Melvyn Sopacua <m.r.sopa...@gmail.com> > 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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.
