> > > Seems to me this has precisely the same meaning (though in a different > > context). In the context of Auth, register_next is the URL after you > > register, and in the context of Crud, create_next is the URL after > > submission of a create form. What's the problem? > > By "precisely the same meaning", do you mean that there is a _next URL > parameter that can override the Crud create_next (and others) field > settings and it is a bug that The Book doesn't say so?
No, I do not mean that. Referencing crud.settings.create_next in the context of discussing auth.settings.register_next, you lamented that you wished things with the same name had the same meaning. I believe these do. There is no _next URL parameter for Crud, as it would not make sense in that context. Are you suggesting Crud shouldn't use the "create_next" terminology merely because Crud doesn't also have a _next URL variable parallel to that of the Auth system? In that case, how exactly do you suggest changing the API? > > Moreover, your suggested fix (to have > > auth.settings.register_next take precedence within the register() > function) > > would actually break the intended behavior. It's important to identify > the > > real problem before attempting a fix. > > Since you wrote: "it does appear that the navbar does not do the same > thing with the login link, and I'm not quite sure why" I don't have > much confidence in your claim to knowing what the intended behavior > is. Note, the code explicitly creates a separate _next link for login (and logout): http://code.google.com/p/web2py/source/browse/gluon/tools.py#1226, but does not do so for register or the other actions, so I think it is safe to assume the intention was for these to behave differently. Furthermore, every place next is defined, it gives precedence to the _next URL parameter over the auth.settings.<action>_next setting (e.g., http://code.google.com/p/web2py/source/browse/gluon/tools.py#1984). Finally, as has been pointed out, the book itself says the auth.settings are there for cases where there is no referrer. To me, this makes sense (use the referrer when present; fall back to the fixed setting otherwise). I therefore infer that the behavior is as intended. If you disagree, please explain. > As I wrote in my first message: > "...I have no idea what else I have subtly screwed up. I don't even > know if I should submit a bug report or if there is some other > configuration I could do that would avoid having to make this code > change." > I'm not sure why you are so concerned. In my original reply<https://groups.google.com/d/msg/web2py/wKd5QN5R5fs/3v3JSqQOtrIJ>, I explained clearly what is going on and how you can implement an easy workaround, pending a new option being added to the navbar helper. Having spent hours reading through the book and then the code to see > what mistake I had made configuring auth.settings and/or my app in > general, I finally had to give up and just use my big hammer solution > so that I could move on to doing more substantial work on my app. What's wrong with the much smaller hammer solution I provided? > No > one has explained why login_next is different nor how it fits into > some notion of what the current design/intent is. login_next works the same as register_next. The difference is in how the navbar generates the login link versus the register link. I agree it's not clear why the login link is treated differently, and I think it should perhaps be changed (though I think it is appropriate to treat the logout link differently). Nevertheless, I don't think this is something to get overly worked up about. Anthony
