On Apr 9, 2010, at 8:09 AM, mdipierro wrote: > 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.
I think we still need a flag (possibly per-app), to recognize the case when there are no args (the canonical form of the URL never has a bare ;). > > 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.
