On Mar 22, 4:57 pm, mdipierro <[email protected]> wrote: > The only relevant files > > gluon/main.py (wsgibase) > gluon/rewrite.py >
I think that gluon/html.py URL will also need some changes for the case when it is used with a request parameter. > Are you planning to modify the routes_in syntax to allow REST? If so I > am interested in it but let's agree on a syntax first. > I must confess that I'd prefer to reuse some existing solution and not try to reinvent a solution as things are not as simple as they may look at first sight. I know Google AppEngine has a a basic routing mechanism in place, but it is far for being complete. Another option I am aware of is Routes [1] which looks better (I haven't used it extensively though and I wasn't really able to find the documentation for the latest release 1.10.3 [2]). If we want to go the routes.py path, what I think it might be needed is: 1. add a configuration option saying if a non-native web2py routing should be used 2. allow definition of complex (regex-based) rewrite rules (f.e.: r'^/some/url/(controller)/here(.html)$' -> '/myapp/\1?format=\2' # 'controller' is the controller r'^/other/url/(controller)/(id).(html)$' -> '/myapp/\1/\2?format=\3' # 'controller' is controller, 'id' will be available through args, etc ) Anyways, I don't find the above is really readable, but I don't really have any other idea on how to preserve as much of the current execution flow. There are some more things that will probably need some work. 1. Case insensitive URLs and CamelCase Python class naming convention Usually I'd prefer to have case insensitive URLs (it is rather stupid to show serve a resource /a/b.html while returning a 404 for /A/ b.html). On the other hand, Python class names are using the camel case notation, so when registering the controllers the names will have to be lowered (same applies to the controller part in the URL). Indeed this can be added as a configuration option. 2. I am not aware of a way to not have to flatten out my project structure so that conversions from url_path_fragment to controller name actually works. With a decently sized webapp, you may start using different packages to group the controllers together. Right now, I do think that all controller names are flatten out (by removing any package/module info -- this is just a guess for now as I haven't really had the time to dig through that part of the code). This is not a major problem though. Looking forward to hearing your comments, ./alex -- .w( the_mindstorm )p. Alexandru Popescu [1] http://routes.groovie.org [2] http://pypi.python.org/pypi/Routes > Massimo > > On Mar 21, 4:13 pm, Alex Popescu <[email protected]> > wrote: > > > Yarko, Massimo, > > > I do understand how web2py routing works. But I do NOT like it as it > > is action based while I am looking for clean REST. > > > As I've pointed out in my first email the URL parsing and 'routing' > > happens in 'gluon.main.wsgibase' (at least for a mod_wsgi deployment) > > and I am pretty sure I know how to make it work as I want, but my > > question is if that is the only modification I need to do or are there > > other places where I should look. > > > Just to clarify the difference between action based URL and REST URL: > > > 1. for action based URLs the HTTP Request method has no impact on > > routing, i.e. a GET, POST, PUT can result in the same function > > invocation (making a GET or POST request to /myapp/controller/ > > dosomething will always invoke dosomething) > > > 2. for a REST app, GET, POST, PUT is THE action identifier and so > > there is no need of the <function_name> in the URL (basically all is > > needed for REST urls is the RESOURCE name) > > > Here is a very basic example: imagine a book management app that > > allows you to Add a book, List existing books and modify the details > > of a book. > > > 1. create a new book > > > REST: POST /myapp/books/ > > > Action based: /myapp/books/create > > (Note: you can use even a GET request to create the book) > > > 2. list existing books: > > > REST: GET /myapp/books/ > > > Action based: /myapp/books/list > > > 3. display an existing book: > > > REST: GET /myapp/books/<book_identifier> > > > Action based: /myapp/books/edit/<book_identifier> > > > 4. update existing book: > > > REST: PUT /myapp/books/<book_identifier> > > > Action based: /myapp/books/update/<book_identifier> > > > As you can see there are major differences between the two approaches. > > I will not discuss here the pros and cons, but only point out that I > > need a way to make web2py RESTy. > > > Moving away from the REST vs action based URLs, a more generic way to > > formulate my question would: is there a way to change the whole > > routing mechanism? > > My app requires various types of URLs that I don't think I will be > > able to route using the current mechanisms. > > > Examples: > > > 1. > > /api/v1.0/<rest_of_url> > > /api/v2.0/<rest_of_url> > > > 2. > > /resource/identifier.html -> HTML representation of the resource > > identified by 'identifier' > > /resource/identifier.json -> JSON representation of the resource > > identified by 'identifier' > > /resource/identifier.xml -> XML representation of the resource > > identified by 'identifier' > > > ... and quite a few others so frankly speaking I am looking for a more > > descriptive but explicit (non-conventional) way to perform the > > routing. > > > Many thanks in advance, > > > ./alex > > -- > > .w( the_mindstorm )p. > > Alexandru Popescu > > > Disclaimer: We are currently starting to prototype a real app and I > > have a pretty clear idea of what I need to accomplish. I have no > > intentions to start flamewars or debates and I am only looking for > > specific features that I know will be needed. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
