Suggestion: make auth login view more dynamic

[Hedde van der Heide]

I couldn't find an existing ticket but I'd like to suggest a change to make the basic auth view more dynamic (I'm not fond of hardcoded context variables :-))

change:

def login(request, template_name='registration/login.html',

          redirect_field_name=REDIRECT_FIELD_NAME,

          authentication_form=AuthenticationForm,

          current_app=None, extra_context=None):

to:

def login(request, template_name='registration/login.html',

          redirect_field_name=REDIRECT_FIELD_NAME,

          authentication_form=AuthenticationForm,

          current_app=None, extra_context=None, form_name='form'):

and obviously:

    context = {

        form_name: form,

        redirect_field_name: redirect_to,

        'site': current_site,

        'site_name': current_site.name,

    }

Kind Regards,

Hedde van der Heide

[Florian Apolloner]

Hi,

-1 from me here.

A) why don't you have site_name_name etc (those are still fixed).

B) templates need to be able to rely on a name, if your template expects a different name user {% with form as my_form %} 

Cheers,

Florian

[Andrew Ingram]

It seems to me there'd be more mileage in making new class-based
versions of the auth views.

- Andy

> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/9xWEYMsvTU8J.
>
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

[Hedde van der Heide]

@Andy, I agree, it's perfectly possible to create you own auth backend now, so theres no need to change it if new views are sceduled. It just felt as a repetitive exercise

@Florian, The other context variables should be dynamic aswell. I don't agree with your template logic. Django always seems to pass this 'form' name in, which is a problem when you have a page with multiple forms coming form django itself (for example: registration and auth). Ofcourse there's logic workarounds, but still, I don't think those should be hardcoded.

Hedde

Met vriendelijke groet,

Hedde van der Heide

Developer & Sales

intellimedia.nl

[T] +31(0)6 - 11 717 441

[E] h.vand...@intellimedia.nl

---

TWITTER @intelli_media

[Florian Apolloner]

Hi Hedde,

On Thursday, May 24, 2012 3:08:22 PM UTC+2, Hedde van der Heide wrote:

@Florian, The other context variables should be dynamic aswell.

No they shouldn't be made dynamic at all (none of them!) -- As Andy suggested CBV are a way better option.

 

I don't agree with your template logic. Django always seems to pass this 'form' name in, which is a problem when you have a page with multiple forms coming form django itself (for example: registration and auth).

But those two forms never end up in the same template, so there is no possibility of a clash etc, login goes to /registration/login.html, registration iteself to /registration/somethingelse.html. And if you really send them to the same template you can't use the builtin views and have to write a new view yourself either way...

Cheers,

Florian

[Hedde van der Heide]

I already said cbvs are the better option however as you said some solutions require custom views, it seems to me persistent login and registration widgets while an anonymous user instance is present are common practice (ie coming from à context processor) it felt repetitive to keep bending views for such à common thing :-) Thanks for raising the bigger picture tho :-)

--

You received this message because you are subscribed to the Google Groups "Django developers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/pcVmO4x9Sv0J.