Hi Anthony,
Yes, my main point being especially that the average user cannot get to the
bottom of it all. I think that this is mostly a question of
documentation, but it would be nice to know what the limitations are so
that time wasting can be avoided when users are trying to find a
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
On Jun 29, 2012, at 5:08 AM, villas wrote:
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
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.
Have
On Jun 29, 2012, at 8:47 AM, villas wrote:
@Jonathan.
Parametric Router. I just read the book again and I had overlooked that with
the parametric router you cannot have app specific routes in the app folder.
That is a shame because I had always thought a main advantage of having an
app
Parametric Router. I just read the book again and I had overlooked that
with the parametric router you cannot have app specific routes in the app
folder.
Actually, according to the example file, you can have app-specific routes
in the app folder if desired:
A controller-name map (or perhaps some generalization of that concept)
would be relatively straightforward in the parametric router. Not sure how
generally useful it'd be.
Something like that would be particularly useful when using plugins, as you
usually do not want plugin_ in your URLs
On Jun 28, 2012, at 5:18 AM, Anthony wrote:
A controller-name map (or perhaps some generalization of that concept) would
be relatively straightforward in the parametric router. Not sure how
generally useful it'd be.
Something like that would be particularly useful when using plugins, as
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
On Jun 27, 2012, at 10:33 PM, 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
Hi All,
I have spent a full day trying to make simple routing work. Please, I
have tried all the routers and read everything I can. Could anyone please
help?
Apache / wsgi standard setup without any changes. Single instance of
web2py
Two domains and two apps:
domain1.com - app1
On Jun 26, 2012, at 7:12 AM, villas wrote:
I have spent a full day trying to make simple routing work. Please, I have
tried all the routers and read everything I can. Could anyone please help?
Apache / wsgi standard setup without any changes. Single instance of web2py
Two domains and
Hi Jonathan and Anthony
Thanks for your comments. I appreciate the work you have done to try and
simplify this tricky subject. However, for me, the parametric router and
other ideas, such as the autoroutes.py and some other recipes I have
seen, are not a good idea, at all.
Now I know
13 matches
Mail list logo
