Nice, that is great news that it already behaves like this :). Definitely gets my vote.
I couldn't see these details elaborated in the web3py thread so was aiming to suggest some clear rules. Guess that makes these suggestions syntactic only. Still to try web3py, will do soon. On Mon, Dec 10, 2012 at 9:33 PM, Massimo Di Pierro < massimo.dipie...@gmail.com> wrote: > web3py does that already. Although it does not support the exact syntax > you proposed. Did you try it? > > > On Monday, 10 December 2012 17:42:20 UTC-6, Robert Clark wrote: >> >> A couple of days ago in the "web3py important!" thread I posted some >> thoughts on URL route matching syntax for the @expose(....) method, but my >> post is yet to surface. Posting a more-considered version here for >> consideration and feedback. >> >> I've been looking into some other frameworks, and Alloy stands out to me ( >> http://alloyframework.org/**manual/url-router/<http://alloyframework.org/manual/url-router/>), >> it's the main inspiration for the syntax below. (Also looked at Flask, >> Silex, Codeignighter, Django and considered trade offs each one brings) >> >> In a URL route lets say that '/' delimits segments, and anything between >> matching '<' and '>' pairs is a segment pattern. Each segment may contain >> either static text or a segment pattern. Segment patterns cannot span '/' >> separators. >> >> 1. Suggest use symbols to define string and integer types in segment >> patterns. ":" = "str", "#" = int (are other types necessary?). So ':' is >> no longer a delimiter. >> @expose('/index/<:company>/<#**ssd>') >> def index(company, ssd): >> '''company is a string, ssd is an int''' >> >> 2. Up to one question mark may be included immediately before any '/' to >> indicate the remaining segment patterns are all optional (and consequently >> map to non-required attributes which may have defaults). By specifying a >> single point in the route beyond which matching segments are optional, it's >> harder to write ambiguous route definitions. >> @expose('/index/<:company>/<#**ssd>?/<#favourite>') >> def index(company, sad, favourite=None): >> >> @expose('index/<:company>/<#**ssd>?/<#favourite>/<#last_** >> visited_article>') >> def index(company, ssd, favourite=None, last_visited_article=1): >> >> 3. Perhaps use "*" as wildcard to match text (including '/') but there >> may be good security reasons not to allow? The constraint could be that no >> segment patterns may follow. Also only one per route. Always a string. >> @expose('index/<:company>/<#**ssd>?/<*rest_of_url>') >> def index(company, ssd, part_of_url='not provided'): >> >> @expose('index/<:company>/<#**ssd>/<*part_of_url>/some-**static-text') >> def index(company, ssd, part_of_url): >> >> 4. Regex. Must match whole segments - i.e. shouldn't be able to split a >> section into multiple parameters with a regex. Keep type - so regex match >> is still passed through as string or int. (E.g. the 4-digit year is passed >> through as 'int' here.). It's not really a validator but could be abused >> that way. >> @expose('index/<:company|[A-**Za-z ]{3,20}>/<#year|[0-9]{4}>') >> def index(company, year): >> >> Cheers >> Rob >> >> >> On Tuesday, November 27, 2012 1:39:06 AM UTC-3, User wrote: >>> >>> I noticed a thread over in web2py-developers web3py - >>> important!<https://groups.google.com/forum/?fromgroups=#!topic/web2py-developers/RCeiRd3Rzs0> >>> which >>> was exciting to read. I've flirted with web2py and there's a lot that I >>> like about it. For some reason I find web2py exciting whereas django >>> doesn't provide that. I've used Yii on the php side which is great >>> framework as far as php goes and asp.net mvc which is great as well. >>> I'd love to work with python but the main thing making me hesitate with >>> web2py is critical mass. >>> >>> It seems like it wouldn't be hard for web2py to really dominate the >>> python web framework space if some of the core criticisms were addressed. >>> I'm not fully up to speed on what they are but I usually hear about unit >>> testing and global variables. It feels like there is a roadblock >>> preventing the project from skyrocketing. Python needs a rails. I >>> understand that the design decisions are by choice with pros and cons. >>> >>> My questions are: >>> 1. Will web3py likely address these often repeated core criticisms? (I >>> saw point 5 from the thread linked to above: "5) No more global >>> environment. Apps will do "from web3py import *" (see below)") >>> 2. The developer thread is over in the developers section. Will you >>> have a more open forum for users (as opposed to developers) to have input >>> on web3py? >>> >>> >>> >> -- > > > > -- robert.cl...@niftybean.com nz.linkedin.com/in/robertclarknz twitter.com/robot88 Niftybean Productions Ltd · niftybean.com PO Box 11463 · Manners Street Central · Wellington 6142 · NZ 021.146.9675 · 04.478.2968 --
