Im trying to insert the registration-form template from django-registration in another html document.
The original Registration template it's working perfectly fine and users are saved in the DB:
This is what happend when i try to insert the registration form in any other html document using {% extend registration/myRegistrationFormTemplate.html %}. Fields are not showed and the submit button don't work.
Also, this is what happend when i try to load myRegistrationFormTemplate.html using the Jquery method .load. Fields are showed but the submit button don't work.
The question is: Why this is happening? and what's the usual procedure to do this?
You might need to use include which allows you to render the included page with the current context. However, this totally depends how you design your templates structure and how they extends other templates. This answer might explain the difference: https://stackoverflow.com/a/2863753/2074398
Thanks FallenAngel you were right, i was missing the view info. And thanks for telling me about "include" almalki, now all it's working right. In my project im using 2 forms in this view and a jquery modal window. To simplify my solution i'll only use one form. I hope this will be useful for someone.
SOLUTION:
View of the template you'll include the form
def patrimonio_view(request,
template_name='home/patrimonio.html'):
#OTHER DB QUERYS
pat = patrimonio.objects.all()
ciu = ciudad.objects.all()
if request.method == 'POST':
if "Registrar_usuario" in request.POST:
#USER REGISTRATION FORM RELATIVE
return register_usuario()
if "Registrar_comerciante" in request.POST:
#MERCHANT REGISTRATION FORM RELATIVE
return register_comerciante()
#RENDER
return render_to_response(template_name,{
'patrimonio':pat,
'ciudad':ciu,
}, context_instance=RequestContext(request))
urls.py
url(r'^patrimonio/$','patrimonio_view',
{'backend_registro_usuario': 'Hesperides.apps.accounts.regbackend_usuario.DefaultBackend','form_class_usuario':RegistrationForm_usuario}, name='vista_patrimonio'),
in the template you will include the form:
{% include "registration/registration_form_usuario.html" %}
Related
I am new to Django, and I would like to try a FBV for an activity that doesn't require a Model. This will eventually implement a search with user-defined parameters and show the results in the template, but for now my template and views are essentially empty to show this problem.
I'm using python 3.6 and Django 2.1.3.
The tutorials go straight to CBV and I'm having a hard time getting good info on the FBV way.
File: 'positivepets/picture_search.html':
-------
{% extends 'positivepets/base.html' %}
{% block body %}
<p> You have reached the picture search page </p>
{% endblock %}
File: urls.py
--------
app_name = 'positivepets'
urlpatterns = [...
url(r'^picture_search/$', views.misc_views.picture_search, name='picture_search'),
...]
File: misc_views.py
--------
def picture_search(request):
return render(request, 'positivepets/picture_search.html')
Problem
This all works fine and renders the template picture_search.html.
My problem is that I want to avoid hardcoding the template name. I thought this would work:
def picture_search(request):
return HttpResponseRedirect(reverse('positivepets:picture_search'))
This takes the user to http://127.0.0.1:8000/positivepets/picture_search/
but produces a "too many redirects" error in chrome. I think I am just telling it to redirect to itself over and over.
Question
Where do I specify that picture_search.html is the template that I want to render without hardcoding it in the view?
It seems that the answer should lie in reverse, but I can only find CBV examples of reverse(), and I think it works with CBV because there is a template_name attribute set in the class definition. FBV doesn't have that, of course.
I'm hoping this is an easy one for someone with some FBV experience.
I don't think there is any benefit in doing what you're trying to do. You have to tell django what template you want by name somewhere. If you don't do it in your return, but somewhere else in your code you've only added a layer of abstraction with no net benefit.
i.e
def picture_search(request):
return render(request, reverse('some_pointer'))
some_pointer = 'picture_search' - you still have to hard code it
= No benefit
the reverse function is for getting the url from the view, or the label.
At the end of that url is some function to render a template, with the template name.
Say you already have a complex HTML form, possible from a designer, front end dev, etc. Is it common practice to not use dynamic forms (based on a Django form) for complicated forms?
I want to do something like this:
1.) Create custom HTML form.
2.) Catch form data through POST request, put it in an object/dictionary.
3.) Do some manipulations with that data to get it in a format acceptable by a Django form.
4.) Pass the manipulated data in to a form object, validate it, etc...
What is a clear solution to this problem? Should I be using Django's dynamic forms for everything? If not - how do I implement the above?
EDIT:
Part of my question has to do with using the forms ONLY for validation. I don't think I made this clear. Here is what I'm trying to do:
template.html
<form method="post">
{% csrf_token %}
<input class="foo" name="bar" type="text" value=""/>
<!-- Some more fields, not rendered through Django form -->
<button type="submit">Create Object</button>
</form>
As you can see, other than the csrf_token there is no Django code here. What I am trying to do in my view is catch the data in the POST in my view, make some changes to the data, then try to bind the new data to a form (not sure if it's possible):
views.py
def my_view(request):
# Some GET code
if request.method == 'POST':
form = ImportedForm(request.POST)
form.data['foo'] = "newValue"
# Now after changing the data, validate it...
If the form and model match nicely then I'll take advantage of the ModelForm functionality.
But most of the time it is not so tidy so, most typically, I do things in about this order:
create a django form with all the field definitions
create django GET view to serve the empty form
create an html template which serves the default html/form
test the blank form
create the POST routine to call validation and reserve the validated (erroneous) form
modify the django form to validate the fields
modify the html form to serve the error messages
test the validation and error messages
modify the POST routine to handle a valid form and do whatever it should do as a result (might involve a redirect and 'thanks' view/template)
Test the whole lot
let the designer loose on the templates
In truth the designer will be involved at some points earlier along the way but in theory I just get it all to work as a "white" then add all the fancy stuff after. That includes javascript validation (ie after all the above).
I ended up doing something like this. It is ugly, and may not be the proper way to do it, but it works...
if request.method == 'POST':
try:
# Create dictionary from POST data
data = {
'foo': request.POST['foo'],
'foobar': request.POST['foobar'],
}
except:
# Handle exceptions
form = ImportedForm(data)
if form.is_valid:
# Continue to validate and save
I have this in my views.py:
def announcements(request):
return render_to_response('events.html', {
'posts1': Blog.objects.filter(category__title="Announcements")
}, context_instance=RequestContext(request)
)
And this in my base.html:
{{ posts1 }}
But nothing from the above request context gets rendered when I load the home page.
Edit 1:
It looks like I am on a wrong path here. My aim is to display the posts under "announcement" category throughout my website in a fixed sidebar. Whichever page is opened the sidebar in that page should contain only posts from "announcement" category. Any suggestion for how to achieve it?
Create an inclusion template tag and use it in templates where you want to display that sidebar.
{% include 'django.contrib.auth.views.login' %}
I don't want to write everything by hand.. I hate this really, django full of automatic stuff.
Goal is to include registration/login.html into base.html, so that I could have this form in every page
If I include only template itself (registration/login.html), problem appears that "form.login", I mean "form" var is not defined because this one comes from VIEW which called when you going to login url. So how can I call that view MANUALLY with include or at least to grab django.contrib.auth.views.login variables by my self in my own view and pass then to base.html?
P.s. It's not just about login form, I think there will be more situations like this
I have found better solution in #django irc.
They called inclusion tags
I'll give you my code, because I got lot's of problem learning new stuff in django =)
file: templatetags/form_login.py
from django import template
register = template.Library()
from django.contrib.auth.forms import AuthenticationForm
#register.inclusion_tag('registration/login.html')
def form_login():
return { 'form': AuthenticationForm() }
Now you can have your form anywhere, this will prerender template and THAT'S IT! no stupid context processors which requires to modify whole project settings.py, which is really sux if you writing stand alone little application..
If you need login-form on every page
Create a context processor:
def login_form_processor(request):
return {
'login_form': LoginForm(request.POST or None)
}
Add it to settings.CONTEXT_PROCESSORS.
Include the template for login form:
{% with login_form as form %}
{% include "registration/login.html" %}
{% endwith %}
You can also make you form lazy-loading, so form will not be created until it is used for the first time.
from django.utils improt functional
def login_form_processor(request):
create_login_form = lambda: LoginForm(request.POST or None)
return {
'login_form': functional.lazy(create_login_form, LoginForm)
}
But I guess you won't want the lazy-loading feature, because login-form is cheap to initialize.
Reusing views
Concerning the "grabbing variables" part from your question: you cannot grab variable from view. Django view is method which returns response object. You can not get variables from response. However some of views accept extra_context and other attributes. Those attributes allow you to configure those views in urls, or to wrap them with your own view, for example:
def my_login_view(request):
some_extra_data = get_some_data()
extra_context = {
'some_extra_var': some_extra_data
}
return login_view(request, extra_context=extra_context, template="my_template.html")
This is not exactly grabbing the variables from views, more like augmentation of existing views.
If you expect to have more situations like this, do less data-porcessing in views. Call some methods which checks for permissions. Collect some data from context-processors. Return rendered response. Now you can reuse the data in other views.
You can specify the action on the form html to point to the URL that accesses the corresponding view.
If you want a form, say called as login_form always populated in all templates, then put it in the context_processors.
Browsing the code for django.contrib.auth.views, you will see that the variables form, site and *site_name* are passed to the template.
Either you (1) provide your custom registration form or (2) you can just import django.contrib.auth.forms.AuthenticationForm in your view if you want to use it.
I have a page, index.html, that contains both a login and registration form. I have a couple of questions about getting this to work properly
My URLConfig looks like this:
urlpatterns = patterns('djangoproject1.authentication.views',
(r'^$',direct_to_template,{'template':'authentication/index.html'}),
(r'^register/$','register'),
)
1) Using the Django book is a guide, my form looks like this:
<h1>Register</h1>
<form action="/register/" method="post">
{{ form.as_p }}
<input type="submit" value="Register">
</form>
Of course, since the file is index.html, the form doesn't appear when I just go to the page. Do I need a "view" to handle visiting index.html rather than a direct_to_template?
2) My Register code looks like this:
def register(request):
if request.method == 'POST':
form = UserCreationForm(request.POST)
if form.is_valid():
new_user = form.save()
return HttpResponseRedirect("/register/success/")
else:
form = UserCreationForm()
return render_to_response("authentication/index.html", {'form': form})
This is the django authentication built-in stuff. Do people actually use it? It seems limited. I know I can add more fields to the Django User by using a user profile or something, but what about the UserCreationForm? Should I roll my own form? Should it inherit from UserCreationForm somehow?
direct_to_template by itself can neither produce nor handle forms -- it simply renders a request directly to a template, as its name describes.
You might look into django-registration for registration.
If you're putting two forms on the same page, you'll need a custom view that is capable of rendering and handling both forms, though multi-form pages are notoriously tricky to work with properly. If you have separate forms (and submit buttons), you can add a unique name to each submit input and determine which form (class) to validate and handle based on if name in request.POST.
edit:
After looking more closely at your code, I see that your registration form redirects to a different view; that simplifies things, but you'll still need a custom view for your home page that passes both login and registration forms to the template for rendering.
Alternatively, if you're simply redirecting to pages that handle each form, you can add those forms using direct_to_template's extra_context parameter directly in your urls.py:
from wherever import LoginForm, RegistrationForm
urlpatterns = patterns('djangoproject1.authentication.views',
(r'^$',
direct_to_template,
{
'template': 'authentication/index.html',
'extra_context': {
'reg_form': RegistrationForm(),
'login_form': LoginForm()
}
}
),
(r'^register/$', 'register'),
)
This approach isn't the cleanest, but it's an option if you really wanted to use generic views.
It sounds like you'll probably want to use a different generic view instead of direct_to_tepmlate. Take a look at the create object generic view. I usually just create a view, typically I end up needing to do more than what a generic view will allow me to do easily.