response.view was what I was looking for (remember seeing it somewhere
but then lost it), thank you guys...

> Rather than providing links to /user/register and then redirecting to
> /register, why not just provide links directly to /register? You don't have
> to route requests to register or to view the profile through the user
> function.
Then the default register/profile URLs will change (unless I do
routing magic and stuff). I really like how Auth ties together
internally, so if possible I'd like to keep everything it holds/
generates (urls, settings, user references, etc.) as is. I know it is
infinitely malleable (feels scary sometimes :)), I actually subclassed
it and my version already does some things differently but still am
trying to do things in a controlled manner. And BTW, Auth.__call__ is
already using this same pattern of splitting functionality by
request.args:
        args = request.args
        #......
        if args[0] in ('login','logout','register','verify_email',
                       'retrieve_username','retrieve_password',
                       'reset_password','request_reset_password',
                       'change_password','profile','groups',
                       'impersonate','not_authorized'):
         #......
so I just thought it may not be that bad of a style reusing it one
level up.

> What does generate_register_form() do? If you want, you can generate the
> default registration form with auth.register(), and then customize the way
> it is displayed in the view.
I am trying to do a SSO / User Management controller for a family of
sites (SSO is over CAS), each site has a different set of required
user attributes, etc. So when I sign you up for a site (or a group of
sites) the registration form is dynamically created (and this is what
generate_register_form() does). Same for the profile one, it creates a
union of all sites' attributes. So far it's going great, web2py
delivers...

Again, thanks for your help!

Reply via email to