First off, I'm very much a newbie when it comes to Django.
The problem I'm struggling with is in trying to create templates for the built-in authentication forms in Django 1.7 but there is very little that I can find in the way of concrete examples anywhere in the documentation or elsewhere.
I can find plenty of questions and examples that describe how to manually create the templates (or copy them from the Django packages) but from what I understand about the Form class and the built-in authentication forms is that I don't need to manually create the actual form in the template. In fact, it seems more desirable to use the Form classes because that would add ensure that fields are named correctly, that the validation such as max length on text fields is applied, etc.
Can anyone point me to some concrete examples or documentation of what I'm talking about? I've read the following sections already,
https://docs.djangoproject.com/en/1.7/topics/forms/
https://docs.djangoproject.com/en/1.7/topics/auth/default/
https://docs.djangoproject.com/en/1.7/topics/auth/customizing/
In fact, I would say that this question extends to any Form class in general but I'm specifically looking at the authentication forms here because I obviously haven't written these Form classes.
I don't think it should make any difference from what I've read since the same process should apply, but I will say that I'm using the django-authtools package (http://django-authtools.readthedocs.org/en/latest/)
I have the actual authentication system working fine. It logs users in and out, I can enforce that certain urls require the user to be logged in first, etc. so its only the actual form display that is an issue.
Related
I'm about to create a form in my website made in Django with elements that have complex input types from different plugins (like calendar plugins). Also, I'll be using a Validator plugin which validates the input before submission.
My question is do I need to create forms.py and like model the form or can I just create the form manually? The former seems like a very hassle process. Which one is more efficient and recommended?
As #dmitryro said you can create your forms manually in the templates and then getting in the request. It's recommended to use the forms api provided by Django since it allows you to reuse, validate, and customize your forms.
As to whether or not it is a good practice that depends completely on you but if you are trying to scale an application I would recommend use the forms.
It is good to use Django's built in form.
If we use django's form then we only have to write python code and django will create corresponding html for it. And our code will be short and clean.
What is the best way to separate your authentication backend logic from code which is inherently dependent on it?
Here's a common problem: django_auth_ldap does not prepopulate the users table, but rather authenticates against LDAP and adds users to the table as they log in for the first time.
However, say we're writing an app that involves adding members to projects. Users may want to add other users who exist in LDAP but have not logged in before, so you're pretty much required to enter a username in this case and query LDAP and the database to see if that user exists. Again though, if we're writing the app to be reuseable, we'd like the "lookup by username" subroutine to be configurable.
At work we've had two different solutions to the problem which both work fine but they are sort of weird solutions.
Make it so you can write a get_user_by_username function in settings.py which does whatever lookups you want
Give a "appname.modelname" path to a proxy model of auth.User you've created which is expected/forced to have a classmethod which does the same things as get_user_by_username
I think the first one is a little cleaner since it doesn't introduce new types, but it's still a weird thing to have in settings.py.
I suggest writing an abstract base class that encapsulates the expected functionality. This acts somewhat like an interface does in programming languages like C# and Java. Then have a django setting that specifies the class to be used for the get_user_by_username provider.
This means that future developers can put their get_user_by_username implementation anywhere they see fit as long as it is implemented in a class derived from the abstract base class and they point to it in settings.
As far as I'm aware, even as of Django 1.5, there's no built-in handling of nested formsets - i.e. I have an arbitrary number of groups, to which I must add an arbitrary number of members, all from the same page. I'm currently trying to use Nathan Yergler's method to do so, but it seems to be broken under Django 1.5.
The gist of the method is to override the group formset's add_fields method to include an inline_formset of members. However, when I create a GroupFormSet instance in the view, regardless of whether I've passed any group instances, I get a ValidationError: 'ManagementForm data is missing or has been tampered with'
For example, a snippet from my view's get_context_data:
group_inst = models.TemplateFieldGroup.objects.filter(name="Study")[0]
context['group_formset'] = forms.GroupFormSet(instance=group_inst)
Has anyone successfully deployed this method under Django 1.5, or perhaps does anyone have a better way to accomplish the same goal?
Slight edit: my 'groups' are actually members of an even larger umbrella: a Template object has multiple TemplateFieldGroups which have multiple TemplateFields. However, even passing GroupFormSet() a proper Template instance doesn't solve the issue at hand.
I had a similar issue recently. I solved it by creating some custom form and formset classes based on the StackOverflow answer from: Django admin - inline inlines (or, three model editing at once)
This method worked well for Django 1.4 but stopped working when I updated to Django 1.5. To solve it I created a github repository: https://github.com/didorothy/mlrma
The README.md explains my specific situation and goals more fully. My solution is focused on the Django admin but could be pieced apart and used alone. To do more than three levels it could be extended.
So the final solution to my problem, and unfortunately I can't say I fully understand it, can be found here on Andrei Petre's (old) blog. http://andreipetre.tumblr.com/post/26203496689/nested-formsets-with-django
I am writing a Django application and using the built-in ORM. I would like to create functionality to provide a form but the template for that form needs to be built on admin side of the application and can change over time.
For instance, initially they have a form that asks for first name, last name but later if they decide to add birthday field admin should be able to go to this template page add birthrate as new field and on client side, users start seeing it. Is there anything already in place that can be used? I was thinking of using something like this but decided to check here and see if there is something better available.
Is it this what your are looking for?
I have never heard about any library for that, because you have pretty much different approaches to handle that!, but check the link, he is explaining better those approaches.
Since I have not found a Related Links app that works with Django 1.0/trunk, I was looking to create my own.
I would like to attach "Related Links" to models in the same generic way that Comments framework or Tags work.
I've looked over the Content Types documentation but can't wrap my head around (nor find much documentation for) how to use Generic inline formsets - which is what I'm pretty sure I have to use, but correct me if I'm wrong.
My specific requirement is to be able to relate these "Related Links" to almost any model, and to have the form available outside of the Admin - I'll have logged in members of a certain role adding these links, in my specific case.
I thought about tearing into the source of the Comments app, but I know that it uses special template tags, etc, and I'm just not sure if that'd be overkill for this task.
Looking for links, extra documentation, and possibly even examples of using the generic inline formsets (in Generic Views), or solving the problem in a different way if I'm approaching it wrong.
EDIT: I've used James Bennett's example of Generic Inlines to construct and successfully use those Related Links in the Admin. So the real question is: How do I use James' Related Links outside of the Admin?
You can use django.contrib.contenttypes.generic.generic_inlineformset_factory for that. It has the same interface as inlineformset_factory (with 2 additional parameters: ct_field and fk_field, they can be used to specify your model's contenttype's related field names instead of inlineformset_factory's fk_name).
Documentation for inlineformset_factory can be found here:
http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#inline-formsets
Documentation for formsets is also useful.