Right not if there is a ; the URL does not pass validation so ; is simply not allowed. We can write this so that if ; is present the new method for parsing is used and urls generated by URL would always follow the new convention. Old convention would still work. I do not see any ambiguity.
On Apr 9, 8:16 am, DenesL <denes1...@yahoo.ca> wrote: > I like the semicolon idea. > But doesn't it imply changing web2py, anywhere where args and vars are > used, like the URL function?. > > On Apr 8, 2:22 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > I think if ; is present it be used by default to delimit the args > > since there cannot be confusion there > > > /a/c/f.ext;a0/a1/a2 > > /a/c/f/a0/a1/a2.ext > > > should be parsed in the same way. > > > routes_in and routes_out should not be affected since they only > > rewrite the URL before web2py interprets it. > > > On Apr 8, 12:43 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > > I just want it to be able to routes_in on both with ; and without ;. > > > > This is because my blog is indexed on google, and I want my old links > > > to still work If I moved over to the ; method. > > > > -Thadeus > > > > On Thu, Apr 8, 2010 at 11:56 AM, Jonathan Lundell <jlund...@pobox.com> > > > wrote: > > > > On Apr 8, 2010, at 9:37 AM, Thadeus Burgess wrote: > > > > >> How will we be able to configure to use one or the other? > > > > > I'm thinking an alternative variable in routes.py. > > > > > Also, there would be (I think) a provision for application-specific > > > > routes.py files, so once the application is resolved at the top level, > > > > the application-specific parsing could either be in the global > > > > routes.py (as now) or the app-specific version. > > > > >> Will it be able to do "Both" at the same time (for routes_in of > > > >> course). I ask since certain web2py sites are scanned in google, you > > > >> don't want the old links to dis-appear. > > > > > Perhaps, but with some restrictions, since using / as the args > > > > separator leads to ambiguities that don't exist with ;. > > > > > I'd like to be able to use standard Python libraries to do the main > > > > parsing work. Seehttp://docs.python.org/library/urlparse.html > > > > > BTW, RFC2396 actually allows a ;-separated parameter on each component > > > > of the path; you could > > > > havehttp://domain.com/app;arg1/ctlr;arg2/function;arg3?query_string. I > > > > don't see a use for that in the web2py architecture, though. > > > > >> -Thadeus > > > > >> On Thu, Apr 8, 2010 at 11:30 AM, mdipierro <mdipie...@cs.depaul.edu> > > > >> wrote: > > > >>> +1 > > > > >>> On Apr 8, 11:25 am, Jonathan Lundell <jlund...@pobox.com> wrote: > > > >>>> (Context: I've been working on URL parsing.) > > > > >>>> One of the difficulties that parsing web2py URLs presents is that > > > >>>> the boundary between /a/c/f and args isn't explicit, along with the > > > >>>> fact that pieces of /a/c/f can be implied (in particular when > > > >>>> routes.py is being used). > > > > >>>> RFC2396 (1998) introduced (or rather extended) the notion of > > > >>>> 'parameters', taking advantage of the fact that ';' is reserved. So > > > >>>> the RFC2396 approach is to write: /a/c/f;parameters?query_string, or > > > >>>> in web2py terms /a/c/f;args?vars. > > > > >>>> That is, the boundary between /a/c/f and args is marked with a > > > >>>> semi-colon instead of a slash. Args can of course be further divided > > > >>>> however one likes; vars is subdivided with '&'. > > > > >>>> What I'm working on is an alternative to (or rather extension to) > > > >>>> the routes.py logic that is capable of supporting arbitrary encoding > > > >>>> where appropriate (especially in args and vars) and that does not > > > >>>> rely on regexes to do the work. The present scheme would remain in > > > >>>> place. > > > > >>>> Which brings me to my question: I'd like to use the ';' convention > > > >>>> to separate /a/c/f from args in this new regime. Does anyone have > > > >>>> any strong feelings about it one way or the other? > > > > >>>> (One last thing: the architecture would be somewhat modular, so that > > > >>>> besides the current mechanism and the one I'm describing, it would > > > >>>> be fairly straightforward to introduce new ones.) > > > > >>> -- > > > >>> You received this message because you are subscribed to the Google > > > >>> Groups "web2py-users" group. > > > >>> To post to this group, send email to web...@googlegroups.com. > > > >>> To unsubscribe from this group, send email to > > > >>> web2py+unsubscr...@googlegroups.com. > > > >>> For more options, visit this group > > > >>> athttp://groups.google.com/group/web2py?hl=en. > > > > >> -- > > > >> You received this message because you are subscribed to the Google > > > >> Groups "web2py-users" group. > > > >> To post to this group, send email to web...@googlegroups.com. > > > >> To unsubscribe from this group, send email to > > > >> web2py+unsubscr...@googlegroups.com. > > > >> For more options, visit this group > > > >> athttp://groups.google.com/group/web2py?hl=en. > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "web2py-users" group. > > > > To post to this group, send email to web...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > web2py+unsubscr...@googlegroups.com. > > > > For more options, visit this group > > > > athttp://groups.google.com/group/web2py?hl=en. -- To unsubscribe, reply using "remove me" as the subject.
