Hi Anthony

IMO most of the difficulty is not having an easy 'flow diagram' for the 
developer so that he can choose what to do.  I agree that we will of course 
have to keep the parametric router now that we have it.  Here are a few 
points:

1. The pattern router should be named the 'comprehensive' router.

2. The parametric router should be named the 'easy', 'lite' or 'limited' 
router.  It should start off by stating its limitations.  Developers can 
then immediately discard it when it doesn't meet their requirements.

3. It should be made very obvious how the routers in the 'root' (/web2py) 
dir interact with the 'app' routes.

4. For example,  I suggest the root router should go something like this:

default_app = myapp 
## default_app will be applied whenever the app is not obviously 
identifiable

apps_with_own_routers = [app1, app2]
## app1, app2 must have their own routers, which may be 'lite' or 
'comprehensive'

## the following routes do not apply to apps_with_own_routers...
## if default_app is also in apps_with_own_routers (which may only be 
determined after all this file has been parsed) then the routes in this 
file are also ignored.

routes_in ...
routes_out ...

I think that if there were a 'flow' like the above,  it would be much 
easier to understand.

With regards plugin_wiki,  as this is a maintained plugin-in I think we 
should have a special regex for renaming this.  It can be exposed as a 
special parameter:  
alt_name_for_plugin_wiki = myprettyname

Or, better still,  a dict solution for all plugins:
alt_names_for_plugins = dict(plugin_wiki=myprettyname)


Please bear in mind that my suggestions are from the point of view of an 
average user rather than a routing guru,  but I hope this perspective might 
nonetheless help.

Regards,
David

On Thursday, June 28, 2012 6:33:58 AM UTC+1, Anthony wrote:
>
> It is usually a good thing that we have choices,  but not choices of blind 
>> alleys.  IMO  there should be one comprehensive way for web2py to do 
>> routes. If regex patterns are the only way to solve all situations then so 
>> be it - we should just get used to it.  All our efforts can then go in 
>> building up a comprehensive list of recipes and off-the-shelf regex 
>> patterns that we can all just use.
>>
>
> The parameter-based system already exists. Can't we keep it and still 
> build up a list of regex recipes? I'm not sure, but I think some of the 
> things the router handles might get a little hairy with regexes 
> (particularly if combined). I think it works well to have any easy to use 
> router system that handles the most common cases, and then a more advanced 
> (but harder to use) system for the trickier cases.
>  
>
>> The fact that there doesn't seem to be a clear answer to my easy question 
>> already says it all,  but the idea of renaming plugin_wiki as a work-around 
>> puts the issue beyond doubt  :)
>>
>
> Is plugin_wiki the core of your site? If so, perhaps you could use the 
> router and make plugin_wiki the default controller (so it is removed from 
> the URL altogether).
>
> Anthony
>

Reply via email to