Anthony, cool. I did come up with a very similar approach.
routes_in = (
(r'^/model1/?$', APPNAME_MODEL1_URL),
(r'^/model1/(?P<ag_id>[^/]*)/?$', APPNAME_MODEL1_ID_URL),
(r'^/model1/(?P<ag_id>[^/]*)/model2/?$', APPNAME_MODEL2_URL),
(r'^/model1/(?P<ag_id>[^/]*)/model2/(?P<cab_id>[^/]*)/?$',
APPNAME_MODEL2_ID_URL),
(r'^/model1/(?P<ag_id>[^/]*)/model2/(?P<cab_id>[^/]*)/model3/?$',
APPNAME_MODEL3_URL),
(r'^/model1/(?P<ag_id>[^/]*)/model2/(?P<cab_id>[^/]*)/model3/(?P<dr_id>[^/]*)/?$',
APPNAME_MODEL3_ID_URL),
(r'^/model1/(?P<ag_id>[^/]*)/model2/(?P<cab_id>[^/]*)/model3/(?P<dr_id>[^/]*)/model4/?$',
APPNAME_MODEL4_URL),
(r'^/model1/(?P<ag_id>[^/]*)/model2/(?P<cab_id>[^/]*)/model3/(?P<dr_id>[^/]*)/model4/(?P<doc_id>[^/]*)/?$',
APPNAME_MODEL4_ID_URL)
)
those variables are there because the URLs were getting a little too
wide to be readable. But so far, that's exactly what we needed (at
least for the proof-of-concept). Thx all for help and participation.
Oh, I ended up using the root routes.py since I just could not get the
app-specific routes.py to work.
On Tue, Mar 20, 2012 at 4:43 PM, Anthony <abasta...@gmail.com> wrote:
> I suppose something like:
>
> routes_in = (
> (r'/appname/model1/$id1/model2/$id2/model3/$id3',
> '/appname/model3/index/$id1/$id2/$id3'),
> (r'/appname/model1/$id1/model2/$id2',
> '/appname/model2/index/$id1/$id2'),
> (r'/appname/model1/$id1', '/appname/model1/index/$id1')
> )
>
> In that case, the values of $id1, $id2, and/or $id3 would be available to
> the respective functions in request.args. Note, the pattern matching stops
> at the first matched pattern, so you have to put the most specific pattern
> first. Also, note that if there are more models/patterns to deal with, you
> could write a function to generate the above list of tuples for you:
>
> def generate_my_routes():
> [code to generate tuples]
> return route_tuples
>
> routes_in = generate_my_routes()
>
> Also, I wonder if you really need separate controllers for each model.
> Perhaps instead you could have a single function in the default controller
> that handles all the data requests from the models. In that case, in a URL
> with model1/{model1_id}/model2/{model2_id}/model3/{model3_id}, model1,
> model1_id, model2, etc. would all be in request.args[0:6]. Your function
> could then parse the request.args and generate the appropriate query to
> return the data.
>
> Anthony
>
> On Tuesday, March 20, 2012 2:06:26 PM UTC-4, rdodev wrote:
>>
>> Now more to our use case: a few days ago I wrote asking how could I
>> accomplish and more logical-relational url scheme. One of the "hard"
>> requirements from our customer is to have no action names in the URL
>> and actions should be distinguished via REST. They also asked us to
>> preserve relationships in the URL. So, the REST was easily
>> accomplished via @request.restful() decorator on the index function of
>> each controller. Now what I'm trying to accomplish is:
>>
>> Assume I have three models: model1 ... model3 (where model1 is the
>> parent of model2 and model2 is parent of model3)
>> And their corresponding controllers: cont1 ... cont3
>>
>> Ideally, a user (assuming already-authenticated), can GET request URL
>> http://domain.com/AppName/model1/{model1_id}/model2/{model2_id} and
>> that should be routed to the default function in cont2 controller
>> passing {model2_is} as param
>> A GET request to http://domain.com/AppName/model1/{model1_id}/model2
>> should also route to the default function of cont2
>> A GET request to
>>
>> http://domain.com/AppName/model1/{model1_id}/model2/{model2_id}/model3/{model3_id}
>> should be routed to the default function of cont3
>>
>> ... and so forth.
>>
>> We already did a proof-of-concept with couple other frameworks, and
>> would certainly like to present web2py as an option because it's
>> otherwise a kickass framework, but the URLs are make-or-break for them
>> and we really have no say in the matter. So any help in this specific
>> case is much appreciated.
>>
>> On Tue, Mar 20, 2012 at 1:09 PM, Jonathan Lundell <jlund...@pobox.com>
>> wrote:
>> > On Mar 20, 2012, at 10:00 AM, Ruben Orduz wrote:
>> >> Not sure why so defensive. All I'm suggesting is that there is
>> >> precedent in simpler routing schemes: consider django's (or Rails'),
>> >> for instance. In django you have a urls.py at the root, and then
>> >> optionally one in your app folder. You have to explicitly tell the
>> >> root urls.py which urls to use for your app. There's no guesswork and
>> >> no contingent and thus no confusion. The routes auto-discovery and
>> >> contingencies, in this case, and in my opinion, are not intuitive and
>> >> I would say against the core python concept of explicit over implicit.
>> >
>> > The rule for the parametric router (as opposed to the pattern-based
>> > router) is that a) you can put an app-specific router in the base
>> > routes.py,
>> > but b) if an app has its own parametric router in its own routes.py, it
>> > overrides the base routers.
>> >
>> > The pattern-based router would need additional syntax to accomplish (a),
>> > though I supposed you could write your regexes cleverly and accomplish the
>> > same general thing.
>> >
>> > I think that's the proper behavior, though it's not an apples-to-apples
>> > comparison.
>> >
>> >
>> >>
>> >> On Tue, Mar 20, 2012 at 12:43 PM, Anthony <abasta...@gmail.com> wrote:
>> >>>> I would suggest the following behavior though:
>> >>>>
>> >>>> routes_in and routes out in the _base_ routes.py should be completely
>> >>>> ignored if routes_app is not commented out.
>> >>>
>> >>> No, it should not. You may have multiple applications, but perhaps
>> >>> only some
>> >>> of them have app-specific routes (i.e., a routes.py file in the
>> >>> application
>> >>> folder). In that case, you want routes_app to match routes that belong
>> >>> to
>> >>> the apps with app-specific routes, but you want any routes that don't
>> >>> match
>> >>> routes_app to fall back to the routes_in/routes_out in your base
>> >>> routes.py
>> >>> file. We do not want to completely ignore routes_in/routes_out any
>> >>> time
>> >>> routes_app is present -- we only want to ignore them for the specific
>> >>> apps
>> >>> that are matched in routes_app.
>> >>>
>> >>>>
>> >>>> routes_app should be always completely ignored in _app-specific_
>> >>>> routes.py
>> >>>
>> >>> I believe this is already the case. The example file even says, "This
>> >>> entry
>> >>> is meaningful only in the base routes.py."
>> >>>
>> >>> It might be easier if you describe the routing you're trying to do so
>> >>> we can
>> >>> help you with your specific case.
>> >>>
>> >>> Anthony
>> >
>> >
