Notas.txt

----------------------------- CREAR ENTORNO VIRTUAL --------------------------

	Instalar paquetes de Python:
		- pip --proxy http://proxy.visa2.com.ar/proxy.pac:8083 install nombre_del_paquete
		- pip3 install --proxy=http://proxy.visa2.com.ar/proxy.pac:8083 nombre_del_paquete

	Actualizar pip:
		- pip --proxy http://proxy.visa2.com.ar/proxy.pac:8083 install --upgrade pip
		- python -m pip --proxy http://proxy.visa2.com.ar/proxy.pac:8083 install --upgrade pip

	Remover paquetes:
		- pip uninstall nombre_del_paquete

	Instalar DJango
		- pip3 install --proxy=http://proxy.visa2.com.ar/proxy.pac:8083 django

	Instalar virtualenv
		- python -m venv nombre_del_entorno_virtual

	Instalar pip
	Luego de descargar el archivo get-pip.py ejecutar
		- python get-pip.py --proxy=http://proxy.visa2.com.ar/proxy.pac:8083

------------------------------------------------------------------------------

-------------------------------- CREAR PROYECTO ------------------------------

	El
	
		django-admin.py
	
	es la utilidad de linea de comandos de DJango, es la que nos apoya para poder crear proyectos, aplicaciones y super usuarios.

	Comandos:
		1- django-admin.py startproject nombre_del_proyecto
		2- django-admin.py startapp nombre_de_la_app
		2- django-admin.py createsuperuser


	El
	
		manage.py

	es un empaquetador de django-admin.py, nos ayuda a crear migraciones. Hacer
	migraciones, correr el servidor, o ver todo el SQL que se crean en las migraciones.

	Comandos:
		1- manage.py makemigrations
		2- manage.py migrations
		3- manage.py runserver


------------------------------------------------------------------------------

--------------- CREAR APLICACIONES Y ESTRUCTURA DEL PROYECTO -----------------

	Para ver la estructura del proyecto ver este video - video 4 - del curso

	Un proyecto en DJango es nuestra aplicacion web.

	Las aplicaciones que se crean con el comando

		django-admin.py startapp nombre_de_la_app

	Son aplicaciones que se crean dentro del proyecto de DJango, pero debemos saber
	distinguir entre lo que es nuestra aplicacion web (el proyecto en si) y una
	aplicacion de DJango (modulo o funcionalidad de nuestro proyecto (aplicacion
	web)).

	Una buena practica es crear una carpeta llamada apps que se encuentra en el
	mismo nivel que el archivo manage.py, dentro de ella se debe crear el archivo
	vacio con nombre

		__init__.py

	para que DJango la reconozca como una carpeta parte del proyecto. Luego posicionandose
	en ella desde la consola se puede crear la app de DJango con el comando anterior.


------------------------------------------------------------------------------

--------------------------- MODELOS Y MIGRACIONES ----------------------------

	Un modelo es la fuente unica y definitiva de los datos de nuestra aplicacion
	Podemos definir un modelo como una tabla en nuestra base de datos

	Los modelos son clases que van a heredar de la clase

		django.db.models.Model

	Por eso tienen atributos, y los atributos van a corresponder a los campos de
	nuestra tabla.

	Cuando se crean los modelos, no es absolutamente necesario colocarle un ID,
	esto porque DJango le coloca de manera automatica un campo ID de tipo autoincrementable
	en la base de datos.

	Una llave, o clave primaria identifica de manera única cada fila de una tabla.
	En los modelos de DJango se puede indicar cual sera esta al momento de crearlos.
	Esto indicando en uno de los atributos que ese sera la llave primaria, pasando
	como parametro primary_key=True:

		atributo = models.CharField(primary_key=True)

	de esta forma se dejaria de utilizar el ID que genera por defecto DJango y se
	comienza a utilizar esta para identificar los campos de la tabla.

	Para crear las tablas correspondientes al modelo en la BD se utiliza el comando

		manage.py migrate

------------------------------------------------------------------------------

-------------------------------- RELACIONES ----------------------------------

	- Relacion de uno a muchos, campo: ForeignKey
			Se define de la siguiente manera: despues de haber declarado nuestro modelo
			le asignamos la llave foranea como se muestra en el siguiente ejemplo:

				class Persona(models.Model):
					atributos...

				class Mascota(models.Model):
					persona = models.ForeignKey(Persona, null=True, blank=True, on_delete=models.CASCADE)
					atributos...

			Donde el atributo persona del modelo Mascota va a ser la llave foranea y
			le pasaremos como parametro el modelo al cual va a apuntar (Persona en este
			caso, el cual ya se definio con aterioridad), el parametro null=True permitira
			guardar valores nulos en la base de datos, el parametro blank=True permite
			guardar en la base de datos sin haber haber ingresado ningun dato en el
			campo persona, el argumento on_delete=models.CASCADE lo pasamos para que
			cuando se borre un registro del modelo Persona, automaticamente se eliminen los registros que estes relacionados con el.

	- Relacion uno a uno, campo: OneToOneField
			La manera en como lo aplicamos a los modelos es igual a como lo hicimos
			con la relacion de uno a muchos:

				class Persona(models.Model):
					atributos...

				class Mascota(models.Model):
					persona = models.OneToOneField(Persona, null=True, blank=True, on_delete=models.CASCADE)
					atributos...

	- Muchos a muchos, campo: ManyToManyField
			Cuando se trabaja con la relacion de muchos a muchos lo que sea hace es
			que se crea otra tabla que va a contener los id de ambas tablas.

			Por ejemplo, si tenemos un modelo llamado Vacuna y lo queremos relacionar
			con otro modelo llamado Mascota, seria algo como:

				Class Vacuna(models.Model):
					atributos...

				Class Mascota(models.Model):
					vacuna = models.ManyToManyField(Vacuna)
					atributos...

	En DJango podemos registrar nuestros modelos para que podamos manipularlos desde
	el administrador que nos trae este framework. Para esto, escribiremos en el
	archivo admin que se encuentra dentro de cada aplicacion:

		admin.site.register(modelo)

	Luego de haberlo importado.

------------------------------------------------------------------------------

------------------------- DJango Shell y Querysets ---------------------------

	El api shell de DJango nos brinda la facilidad de poder interactuar con nuestros
	modelos y objetos mediante el.

	Los querysets, permiten realizar lecturas, filtrado y ordenamientos en la base
	de datos.

	Lo primero que se hace al querer interactuar con los modelos, es importarlos



	El shell de DJango inicia con el comando

		manage.py shell

	Y los modelos se importan de igual manera que como se hace en los .py

		from directorio.aplicacion.models import Modelo


	Para registrar un objeto desde el shell de DJango se puede hacer de dos maneras:

		- Modelo.objects.create(atributo1 = valor,
														atributo2 = valor,
																		-
																		-
																		-
														atributo n = valor)

		- Asignar a una variable los atributos del modelo

				variable = Modelo(atributo1 = valor,
												  atributo2 = valor,
															    -
																	-
																	-
													atributo n = valor)

			Se guarda el objeto con

				variable.save()


	Desde el shell de DJango se puede asignar la llave foranea a un objeto de la
	BD.

	Con el Queryset:

		Modelo.objects.all()

	se muestra en el shell los objetos que hay en el Modelo


	Se puede filtrar utilizando el metodo filter:

		Modelo.objects.filter(valor_para_filtrar)

		por ejemplo

		Persona.objects.filter(id=2)
		Persona.objects.filter(nombre__contains="Jose")



		Ejemplo del uso del Shell

			(curDJango) D:\Cursos\codigofacilito\DJango\cursoDjango>manage.py shell
			Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:06:47) [MSC v.1914 32 bit (Intel)] on win32
			Type "help", "copyright", "credits" or "license" for more information.
			(InteractiveConsole)
			>>> from apps.mascota.models import Vacuna, Mascota
			>>> from apps.adopcion.models import Persona
			>>> Persona.objects.create(nombre = "Eduardo",
			... apellidos = "Perez",
			... edad = 23,
			... telefono = "1165801254",
			... email = "edujpp1@gmail.com",
			... domicilio = "Libertad 942")
			<Persona: Persona object (1)>
			>>> variable = Persona(nombre = "Eduardo Jose",
			... apellidos = "Perez Pe#a",
			... edad = 23,
			... telefono = "1165801254",
			... email = "edujpp@hotmail.com",
			... domicilio = "Argentina")
			>>> variable.save()
			>>> mascota1 = Mascota(nombre = "Luca",
			... sexo = "Macho"
			... , edad_aproximada = 2,
			... fecha_rescate = "2018-07-24",
			... persona = variable)
			>>> mascota1.save()
			>>> v1 = Vacuna(nombre = "vacuna 1")
			>>> v1.save()
			>>> v2 = Vacuna(nombre = "vacuna 2")
			>>> v2.save()
			>>> mascota1.vacuna.add(v1, v2)
			>>> Persona.objects.all()
			<QuerySet [<Persona: Persona object (1)>, <Persona: Persona object (2)>]>
			>>> Persona.objects.filter(id=2)
			<QuerySet [<Persona: Persona object (2)>]>
			>>> Persona.objects.filter(nombre__contains="Jose")
			<QuerySet [<Persona: Persona object (2)>]>
			>>> exit()

------------------------------------------------------------------------------

--------------------- CONFIGURAR URLS Y PRIMERA VIEW -------------------------

	Para comenzar a crear las vistas, iremos al archivo views.py. En el, importaremos la clase HttpResponse con la sentencia

		from django.http import HttpResponse

	En el archivo settings.py que se crea cuando creamos el proyecto tenemos la variable 

		ROOT_URLCONF

	Que es a la que se le asigna lo que son las URLS globales de nuestro proyecto
 que se encuentran en el mismo directorio, en el archivo urls.py.


	En el archivo

		urls.py

	Es donde podemos incluir las urls de cada una de nuestras aplicaciones. Pero,
	para yo poder incluir las urls de las apps, hay que crear en la app, un archivo que se llame urls.py. Este tendra un contenido similar al que es generado
	por python en el archivo url.py global.

	Dentro de la variable

		urlpatterns

	Sera en donde vamos a listar las urls de las aplicaciones. Seria al como

		from django.contrib import admin
		from apps.mascota.views import index

		urlpatterns = [
		    path('', index),
		]

	En el metodo path, el primer parametro es la url, como en este caso es un index
	se coloca vacio.
	El segundo parametro es la vista que se va a ejecutar al momento en que reciba
	esa peticion de la url.

	Para poder incluir estas urls en las urls globales. Se crea una url en el archivo global de urls y se le indica que url incluira:

		urlpatterns = [
		    path('admin/', admin.site.urls),
		    path('admin/', include('apps.mascota.url')),
		]


------------------------------------------------------------------------------

----------------------------- SISTEMA PLANTILLAS -----------------------------

	Los sistemas de plantillas permiten separar todo lo que es la logica de nuestra
	aplicacion, del aspecto visual, lo que viene siendo nuestro HTML.

	Herramientas del sistema de plantillas de DJango:
		- Variables
		- Tags (etiquetas)
		- Herencia 


	Las VARIABLES las vamos a identificar porque van a estar encerradas entre llaves dobles, ejm:

		<tbody>
			<tr>
				<td>{{ mascota.nombre }}</td>
				<td>{{ mascota.edad_aproximada }}</td>
				<td>{{ mascota.fecha_rescate }}</td>
			</tr>
		</tbody>

	Esto lo vamos a utilizar cuando queramos renderizar, o mostrar, valores que 
	hemos enviado en el contexto (informacion enviada por la vista al template)
	de nuestras vistas.



	Los TAGS se encuentran encerrados entre llaves y signos de porcentajes. Por
	ejemplo con el flujo de control for, seria:

		<tbody>
			{% for mascota in mascotas %}
				<tr>
					<td>{{ mascota.nombre }}</td>
					<td>{{ mascota.edad_aproximada }}</td>
					<td>{{ mascota.fecha_rescate }}</td>
				</tr>
			{% endfor %}
		</tbody>

	Estos nos brindan la facilidad de realizar flujo de control o carga informacion
	externa de los templates.

	Un ejemplo con la sentencia if, seria:

		<tbody>
			{% if mascotas %}
			{% for mascota in mascotas %}
				<tr>
					<td>{{ mascota.nombre }}</td>
					<td>{{ mascota.edad_aproximada }}</td>
					<td>{{ mascota.fecha_rescate }}</td>
				</tr>
			{% endfor %}
			{% else %}
				<h4> No existen registros de mascotas </h4>
			{% endif %}
		</tbody>

		El tag de load staticfiles nos va a servir en todos nuestros templates para
		cargar, o servir, nuestro archivos estaticos, que se debe colocar unicamente
		antes de cargar los archivos estaticos. Ejm:

			<!DOCTYPE html>
			<html lang="es">
			<head>
				{% load staticfiles %}
				<meta charset="utf-8">
				<title>Document</title>
				}
			</head>
			<body>
			
			</body>
			</html>



	La HERENCIA DE PLANTILLAS, reduce la duplicacion y redundancia de elementos
	comunes de los templates, como un title, un header, un navbar, un footer.

	Gracias a la herencia de plantillas, lo que haremos sera crear un esceleto o
	un documento base el cual va a contener estos elementos que necesitan replicarse,
	y en nuestros otros templates podremos heredar estas plantillas, mediante otro
	tag que se llama extends, y asi extendiendo del archivo base podremos sobreescribir
	toda esta parte de la estructura.

	La ubicacion de las plantillas se le indican a DJango desde el archivo

		settings.py

	buscar la variable

		TEMPLATES

	dentro de ella buscaremos el elemeto

		DIRS

	y dentro del arreglo escribiremos

		os.path.join(BASE_DIR, 'templates')

	que quiere decir: buscame una carpeta que se llama templates que esta en la
	raiza de la carpeta contenedora del proyecto.

	El elemento

		APP_DIRS

	que se encuentra dentro de la variable TEMPLATES, cuando esta en True, quiere
	decir que cuando se busque un template tambien lo va a buscar dentro de la carpeta
	de cada una de nuestras aplicaciones, es decir, podemos organizar nuestros templates de dos maneras:

		1- Una sola carpeta en la raiz de la carpeta contenedora de nuestro proyecto
		donde podemos almacenar todos nuestros templates.
		2- En cada aplicacion, dentro de ella, generamos otro directorio que se llame
		templates, el cual va a contener nuestros templates de nuestras aplicaciones.

------------------------------------------------------------------------------

------------------------- HERENCIA DE PLANTILLAS -----------------------------

	Se hereda entre templates con el tag extendes, mediante la siguiente sintaxis

		{% extends 'ruta/template.html' %}


	Desde las vistas, se llaman a los templates utilizando el shortcuts render,
	por ejm:

		def index(request):
			return render(request, 'ruta/template.html')

	Para sobreescribir los bloques de las plantillas heredadas se abre y se cierra
	el bloque en la platnilla que esta heredando y se colcoa el contenido que se
	quiere tener.

	El sistema de plantillas de DJango tambien nos permite hacer includes. Esto
	el tag include:

		{% include 'ruta/template.html' %}

	Sin embargo, no es muy recomendable.


	En los templates base no es muy recomendable cargar los archivos CSS y JS
	que vamos	a utilizar, pues, puede suceder que hayan templates donde no haga
 	falta cargar todos estos archivos. Una buena practica es crear un bloque 'extrahead'
 	para colocar luego en los templates los CSS y un extrajs para colocar los JS.

------------------------------------------------------------------------------

----------------------- CONFIGURAR ARCHIVOS ESTATICOS ------------------------

	Para indicarle a DJango donde tiene que buscar nuestros archivos estaticos debemos
	ir al documento

		settings.py
	
	Declaramos otra variable, que se llamara

		STATICFILES_DIRS

	Y le indicaremos donde tiene que buscar los archivos:

		STATICFILES_DIRS = (os.path.join(BASE_DIR, 'nombre_de_la_carpeta_donde_estan_los_archivos_estaticos'), )

	La etiqueta static

		<link rel="stylesheet" href="{% static 'css/boostrap.min.css' %}">
		<script src="{% static 'js/boostrap.min.js' %}"></script>

	Es necesaria para poder hacer referencia a todos nuestros archivos estaticos.
	El tag static lo que hace es arrojar la ruta absoluta donde se encuentra alojado
	el archivo.

------------------------------------------------------------------------------

-------------- FORMULARIOS Y VISTAS BASADAS EN FUNCIONES CREAR ---------------

	Se crearan formularios para agregar registros a nuestros modelos.

	Una buena practica es crear un archivo, dentro de las apps, llamado

		forms.py

	Y crear alli los modelos que manipularan los formularios y dentro de el seguir
	la siguiente forma de crearlos.


	Los forms de DJango se importan con

		from django import forms

	Y se puede utilizar en funciones como:

		class NombreFuncion(forms.ModelForm)

	Se crea una clase meta dentro de la clase anterior y aca se le indica de que
	modelo va a ser el formulario

		class NombreFuncion(forms.ModelForm):

			class Meta:
				model = NombreModelo

	Los campos que queremos que tenga nuestro formulario se agregan como una lista
	por medio de declarar fiels:

		class MascotaForm(forms.ModelForm):

		class Meta:
			model = NombreModelo

			fields = [
				'campo1',
				'campo2',
				'   -  ',
				'   -  ',
				'   -  ',
				'campoN',
			]

	Luego se agregan los labels que tendran cada cada campo

		class Meta:
			model = NombreModelo

			fields = [
				'campo1',
				'campo2',
				'   -  ',
				'   -  ',
				'   -  ',
				'campoN',
			]
			labels = {
				'campo1': 'descripcion1',
				'campo2': 'descripcion2',
				'   -  ': '      -     ',
				'   -  ': '      -     ',
				'   -  ': '      -     ',
				'campoN': 'descripcionN',
			}

	Y por ultimo los widgets, que son las etiquetas HTML que veremos en el navegador
	pueden ser TextInput, select, CheckBox y etiquetas especiales que trae DJango:

		class Meta:
			model = NombreModelo

			fields = [
				'campo1',
				'campo2',
				'   -  ',
				'   -  ',
				'   -  ',
				'campoN',
			]
			labels = {
				'campo1': 'descripcion1',
				'campo2': 'descripcion2',
				'   -  ': '      -     ',
				'   -  ': '      -     ',
				'   -  ': '      -     ',
				'campoN': 'descripcionN',
			}
			widgets = {
				'campo1',: forms.TipoDeEtiquetaHTML(attrs={'parametroCSS':'valorDelParametroCSS'}),
				'campo2',: forms.TipoDeEtiquetaHTML(attrs={'parametroCSS':'valorDelParametroCSS'}),
															-
															-
															-
				'campoN',: forms.TipoDeEtiquetaHTML(attrs={'parametroCSS':'valorDelParametroCSS'}),
			}


	Una vez que se crea el formulario, se procede con la vista. Que sera la que
	va a recibir la peticion y se va a ejecutar. Por ahora trabajaremos con vistas
	basadas en funciones. Las vistas basadas en funciones, son de versiones antiguas
	de DJango, pero no esta demas conocerlas, pues su uso es poco, pero lo hay.

	Un ejemplo de vista seria:

		def mascota_view(request):
			if request.method == 'POST':
				form = MascotaForm(request.POST)
				if form.is_valid():
					form.save()
				return redirect('mascota:index')
			else:
				form = MascotaForm()
			return render(request, 'mascota/mascota_form.html', {'form':form})


	Que en pseudocodigo seria

		- Definicion de la vista basada en funcion
			- Si el request es un POST
				- Se recibiran los datos que se estan enviando en el POST de nuestro form
				- Si los datos ingresados son validos
					Se guardan
				- Se redirige a ('NombreDeEspacio':'Url')
			- Sino
				- Se vuelve a cargar el form
			- Se retorna la respuesta con render(request, 'nombreDelTemplate', {'contexto':contenido})


	El formulario se importaria en la vista con

		from apps.mascota.forms import MascotaForm

	Para que la vista sea redirigida con la sentencia

		return redirect('mascota:index')

	Es necesario ya haber declarado el espaciado de nombre de 'mascota' en el archivo principal settings.py con la sentencia

		path('mascota/', include(('apps.mascota.urls', 'mascota'), namespace="mascota")),

	Y para utilizar el 'index', se debe agregar en la variable urlpatterns del 
	archivo urls.py de la apps mascotas la sentencia:

	urlpatterns = [
    path('', index, name='index'),
    path('nuevo', mascota_view, name='mascota_crear'),
	]

	Es igual para cualquier otra vista o app.


	para que funcione el shortcut redirec se debe agregar con

		from django.shortcuts import redirect

		o, si son varios shortcuts:

			from django.shortcuts import render, redirect



	Luego si se puede modificar el template para indicar como se vera el form con
	algo tan sencillo como:

		{% extends 'base/base.html' %}

		{% block content %}
			<form method="post">
				{% csrf_token %}
				{{ form.as_p }}
				<button type="submit">Guardar</button>
			</form>
		{% endblock %}


	Hay que recordar que en nuestra vista le estamos enviando el contexto, que es
	nuestro form, en la ultima sentencia

		return render(request, 'mascota/mascota_form.html', {'form':form})

	En la sentencia

		{{ form.as_p }}

	Estamos metiendo en una variable el form que estamos recibiendo en el contexto y con el 'as_p' se le esta indicando que se dibujara en el navegador
	el form como parrafo. Es decir, dentro de puras etiquetas HTML <p>

	Tambien podriamos crear los divs de 'form-group' y acceder a cada elemento del
	form de la manera:

		{{ form.nombreDelAtributo }}

	Y mostraria en el navegador solo esa etiqueta.

	El token de seguridad que nos provee DJango

		{% csrf_token %}	

	es muy importante incluirlo en todos los formularios, comenzando porque si no
	lo hacemos, nos marcara un error.


	Para que la llave foranea (persona) y el campo ManyToMany (vacuna) muestren
	su contenido y no los objetos como tal se debe agregar en los models la funcion

		def __str__(self):
			return "{} {}".format(self.nombre, self.nombre)

	Esto devolvera en el modelo de la app adopcion cuando se acceda al objeto,
	los atributos del primer y segundo campo

	Y en la app mascota, en el modelo vacuna

		def __str__(self):
			return '{}'.format(self.nombre)

	Devolvera el nombre de la vacuna.

------------------------------------------------------------------------------

--------------- LISTAR REGISTROS (VISTAS BASADAS EN FUNCIONES) ---------------

	Vista de ejemplo

	def mascota_list(request):
		mascota = Mascota.objects.all()
		contexto = {'mascotas':mascota}
		return render(request, 'mascota/mascota_list.html', contexto)

	En pseudocodigo:

		- Definicion de la vista basada en funcion
			- Definicion del QuerySet trayendo todos los objetos que estan en el modelo mascota
			- Envio del QuerySet en la variable contexto, que tendra asignado el diccionario
			- Retorno de la respuesta con render(request, 'nombreDelTemplate', variable)


	Luego, para mostrar en el HTML lo que contiene el modelo se utilizo para este 
	ejm el archivo HTML, en el cual un trozo de codigo es:

		{% if mascotas %}
			{% for mascota in mascotas %}
				<tr>
					<td>{{ mascota.id }}</td>
					<td>{{ mascota.nombre }}</td>
					<td>{{ mascota.sexo }}</td>
					<td>{{ mascota.edad_aproximada }}</td>
					<td>{{ mascota.fecha_rescate }}</td>
					<td>{{ mascota.persona.nombre }} {{ mascota.persona.apellidos }}</td>
				</tr>
			{% endfor %}
		{% else %}
			<h1>No hay mascotas registradas</h1>
		{% endif %}

	En pseudo codigo:

		- Si existen registros en nuestro contexto
			- Para mascota en el contexto 'mascotas' (O generar el ciclo for para generar
				un tr por cada registro de la tabla)
				- Trae de mascota el id al td
				- Trae de mascota el nombre al td
				- Trae de mascota el sexo al td
				- Trae de mascota la fecha de rescate al td
				- Trae de mascota el nombre y apellidos de la persona al td
			- Fin del ciclo for
		- Sino
			- Genera el h1 que dice: No hay mascotas registradas
		- Fin del if

		Esta es una manera muy sencilla de listar los registros de nuestros modelos.

------------------------------------------------------------------------------

------------- VISTAS BASADAS EN FUNCIONES ACTUALIZAR Y ELIMINAR --------------

	Se creo la vista para editar un modelo de la app mascota

	def mascota_edit(request, id_mascota):
		mascota = Mascota.objects.get(id=id_mascota)
		if request.method == 'GET':
			form = MascotaForm(instance=mascota)
		else:
			form = MascotaForm(request.POST, instance=mascota)
			if form.is_valid():
				form.save()
			return redirect('mascota:mascota_listar')
		return render(request, 'mascota/mascota_form.html', {'form':form})

	En pseudocodigo:

	- Definicion de la vista basada en funcion que recibe el parametro request y un id
		- Se crea el QuerySet que obtendra el objeto al cual corresponde el objeto
			que se le esta enviando
		- Si el metodo es un GET
			- Cargara la informacion del form con una instancia del obj que se cargo
				en la variable mascota con el QuerySet
		- Sino
			- Toma el POST del form y se instancia el obj mascota que fue el que capturamos
				para que se guarden los cambios que estamos mandando
			- Si el form es valido
				- Guarda los cambios
			- Redirige al listado de las mascotas
		- Se retorna un render al mismo template que se utiliza para registrar mascotas
			enviando como contexto el form


	Para que la url sea dinamica y muestre el form con los datos cargados de la
	mascota seleccionada se coloca

		path('editar/<int:id_mascota>/', mascota_edit, name='mascota_editar'),

	Con la expresion regular

		<int:id_mascota>

	Recibe el segundo parametro que le estamos enviando.



	Para llegar a la vista de editar se agrego en el mascota_list.html un boton
	que redirige a la url de editar:

		<a class="btn btn-primary" href="{% url 'mascota:mascota_editar' mascota.id %}">Editar</a>

	Se redirecciona en el tag url

		{% url 'mascota:mascota_editar' mascota.id %}

	Que recibe como primer parametro la url que creamos para editar y como segundo
	parametro el id de la mascota


	El codigo para eliminar es relativamente similar:

	def mascota_delete(request, id_mascota):
		mascota = Mascota.objects.get(id=id_mascota)
		if request.method == 'POST':
			mascota.delete()
			return redirect('mascota:mascota_listar')
		return render(request, 'mascota/mascota_delete.html', {'mascota':mascota})

	En pseudocodigo

	- Definicion de la vista basada en funcion que recibe el parametro request y un id
		- Se crea el QuerySet que obtendra el objeto al cual corresponde el objeto
			que se le esta enviando
		- Si el metodo es un POST
			- Llamamos al obj que obtuvimos y lo eliminamos
			- Retorna al listado
		- Retorna un render al template delete enviando como contexto el obj mascota


	Se puede organizar la tabla para que salga ordenada por el id. Esto es con:

		mascota = Mascota.objects.all().order_by('id')

------------------------------------------------------------------------------

-------------- VISTAS BASADAS EN CLASES, LISTVIEW Y CREATEVIEW ---------------

	A partir de DJango 1.3 tenemos las vistas basadas en clases. Que son vistas
	genericas de las cuales podemos aprovechar las bondades de la programacion orientada
	a objetos.

	Tenemos dos tipos de vista provistas por DJango, la ListView y la CreateView.
	La primera sirve para listar y la segunda para crear o guardar registros.

	Luego de importar

		from django.views.generic import ListView, CreateView


	Se puede crear la siguiente clase para observar el uso del ListView

	class MascotaList(ListView):
		model = Mascota
		template_name = 'mascota/mascota_list.html'

	En pseudocodigo

		- Declara la clase MascotaList que hereda de la clase ListView
			- Se indica el modelo
			- Se indica a que template se enviara el contexto

	Se modifica en los urls

		path('listar', MascotaList.as_view(), name='mascota_listar'),

	Luego de haber importado la vista basada en clases en

		from apps.mascota.views import index, mascota_view, mascota_list, mascota_edit, mascota_delete, MascotaList, MascotaCreate

	Ahora cuando se haga la peticion a esta url se ejecutara la vista MascotaList, pero por ser una clase se le indica mediante el metodo as_view() que se va a ejecutar como una vista.

	En el template mascota_list.html, como ya no estamos mandando nuestro contexto
	como un diccionario que se llama mascota, nuestra ListView, lo manda como un
	object_list, asi que se modifica como sigue:

		{% if object_list %}
			{% for mascota in object_list %}
										-
										-
										-
			{% endfor %}
						-
						-
						-
			{% endif %}


	Para crear objetos podriamos tener algo como

	class MascotaCreate(CreateView):
		model = Mascota
		form_class = MascotaForm
		template_name = 'mascota/mascota_form.html'
		success_url = reverse_lazy('mascota:mascota_listar')

	En pseudocodigo:

	- Declara la clase MascotaCreate que hereda de la vista generica CreateView
		- Se le indica el modelo
		- Se le indica que form se va a utilizar para generar esta vista
		- Se le pasa el template
		- Se redirige con el atributo success_url y el url resolver reverse_lazy

	Se modifica el url bajo los mismos terminos que con la clase MascotaList

		path('listar', MascotaList.as_view(), name='mascota_listar')

------------------------------------------------------------------------------

------------- UPDATEVIEW Y DELETEVIEW, VISTAS BASADAS EN CLASES --------------

	Cuando se crean vistas que heredan de las vistas genericas de Django con
	urls dinamicos piden por default el parametro pk (primary key). Entonces el configurar el url de la vista editar basada en clases, seria

		path('editar/<pk>/', MascotaUpdate.as_view(), name='mascota_editar'),


	Como se esta trabajando con listas basadas en clases hay que realizar una peque#a
	modificacion al template de 'mascota_delete.html' en la seccion

		<h3>¿Desea eliminar el registro de {{ mascota.nombre }}</h3>

	Pues aca se esta accediendo al atributo para mostrar el nombre de la mascota.
	Ya que la vista esta basada en clases manda el objeto como un object_list, entonces,
	como lo que esta enviando es un object se accede al objeto y se le indica que
	coloque el nombre

		<h3>¿Desea eliminar el registro de {{ object.nombre }}</h3>

	
	Se pueden sobreescribir metodos de las clases genericas (como los POST, los
	GET, los DELETE, los GET con TEXTDATA)

------------------------------------------------------------------------------

---------------------- CRUD CON DOS FORMULARIOS PARTE 1 ----------------------

	Manipularemos dos forms de dos modelos distintos, pero, relacionados entre si
	en un mismo template.

	A partir de DJango 1.9 al asignar una llave foranea se le debe colocar el atributo
	on_delete=models.CASCADE, al momento de crear el modelo, sino, no permitira
	crearlo

		persona = models.ForeignKey(Persona, null=True, blank=True, on_delete=models.CASCADE)

	

	Como se vio anteriormente, una buena practica es crear un archivo forms.py en
	el cual luego de importar la clase para formularios de DJango y los modelos
	con los que trabajaremos en ellos, ejm:

		from django import forms
		from apps.adopcion.models import Persona, Solicitud

	Vamosa a comenzar a indicar cuales son los campos, las etiquetas para cada campo
	y que tipo de campo de un formulario sera, en la clase meta correspondiente
	a cada formulario (los cuales, tambien, son clases), ejm:

		class PersonaForm(forms.ModelForm):

			class Meta:
				model = Persona
				fields = [
					'nombre',
					'apellidos',
					'edad',
					'telefono',
					'email',
					'domicilio',
				]
				labels = {
					'nombre': 'Nombre',
					'apellidos': 'Apellidos',
					'edad': 'Edad',
					'telefono': 'Telefono',
					'email': 'Correo electronico',
					'domicilio': 'Domicilio',
				}
				widgets = {
					'nombre':forms.TextInput(attrs={'class':'form-control'}),
					'apellidos':forms.TextInput(attrs={'class':'form-control'}),
					'edad':forms.TextInput(attrs={'class':'form-control'}),
					'telefono':forms.TextInput(attrs={'class':'form-control'}),
					'email':forms.TextInput(attrs={'class':'form-control'}),
					'domicilio':forms.Textarea(attrs={'class':'form-control'}),
				}


		class SolicitudForm(forms.ModelForm):

			class Meta:
				model = Solicitud
				fields = [
					'numero_mascota',
					'razones',
				]
				labels = {				
					'numero_mascota': 'Numero de mascota',
					'razones': 'Razones para adoptar',
				}
				widgets = {
					'numero_mascota':forms.TextInput(attrs={'class':'form-control'}),
					'razones':forms.Textarea(attrs={'class':'form-control'}),
				}


	Luego, en la vista (archivo views.py de la app adopcion) importaremos
		from apps.adopcion.models import Persona, Solicitud
		from apps.adopcion.forms import PersonaForm, SolicitudForm

	Para poder hacer uso de ambos forms y de los modelos que se manipularan en
	ellos

		class SolicitudCreate(CreateView):
			model = Solicitud
			template_name = 'adopcion/Solicitud_form.html'
			form_class = SolicitudForm
			second_form_class = PersonaForm
			success_url = reverse_lazy('adopcion:solicitud_listar')

			def get_context_data(self, **kwargs):
			    context = super(SolicitudCreate, self).get_context_data(**kwargs)
			    if 'form' not in context:
			    	context['form'] = self.form_class(self.request.GET)
			    if 'form2' not in context:
			    	context['form2'] = self.second_form_class(self.request.GET)
			    return context

			def post(self, request, *args, **kwargs):
				self.object = self.get_object
				form = self.form_class(request.POST)
				form2 = self.second_form_class(request.POST)
				if form.is_valid() and form2.is_valid():
					solicitud = form.save(commit=False)
					solicitud.persona = form2.save()
					solicitud.save()
					return HttpResponseRedirect(self.get_success_url())
				else:
					return self.render_to_response(self.get_context_data(form=form, form2=form2))
	
	En pseudocodigo seria:

		- Declaracion de la vista basada en clases que hereda de CreateView
			- Se indica el modelo con el que se trabajara en la vista
			- Se indica a que template se enviara el contexto
			- Se crea el primer formulario para ser agregado al contexto
			- Se crea el segundo formulario para ser agregado al contexto
			- Redirecciona a otra vista al obtener el success al querer guardar en
				los forms
			
			- Se sobreescribe la funcion get_context_data
				- Se toma el conexto que es igual a la superclase SolicitudCreate y tomando
					el contexto
				- Si form no esta en el contexto
					- se agrega form al contexto al hacer el GET
				- Si form2 no esta en el contexto
					- Se asigna al contexto al haber un GET request
				- Se retorna el contexto

			- Se sobreescribe el metodo post
				- Se accede al objeto
				- Se toma la info de form
				- Se toma la info de form2
				- Si form y form2 son validos
					- Se crea la variable que guardara el primer request pero sin guardar
						en la base para poder guardar tambien los valores de form2
					- Se ingresan en el atributo persona lo obtenido en form2 y se guardan
						en la BD
					- Se redirecciona al success_url qur lleva a la vista solicitud_listar
				- Sino
					Se devuelve el contexto, que son los forms (form1 y form2)


	Ahora para cargar los forms en el template solicitud_form

		{% extends 'base/base.html' %}

		{% block content %}
		<form method="post">
			{% csrf_token %}
			{{ form2.as_p }}
			{{ form.as_p }}

			<button type="submit">Guardar</button>
		</form>
		{% endblock %}

	Entonces observamos que luego de pasar el token de seguridad de Django (csrf_token)
	le pasamos el segundo y primer form

------------------------------------------------------------------------------

--------------------- CRUD CON DOS FORMULARIOS PARTE 2 -----------------------

	En el archivo views.py de la app adopcion se tiene una nueva clase

		SolicitudUpdate

	Para actualizar la info de una solicitud. Para obtener la info de la solicitud
	que se va a modificar, modificaremos dentre de esta clase la funcion

		def get_context_data(self, **kwargs):
			context = super(SolicitudUpdate, self).get_context_data(**kwargs)
			pk = self.kwargs.get('pk', 0)
			solicitud = self.model.objects.get(id=pk)
			persona = self.second_model.objects.get(id=solicitud.persona_id)
			if 'form' not in context:
				context['form'] = self.form_class()
			if 'form2' not in context:
				context['form2'] = self.second_form_class(instance=persona)
			context['id'] = pk
			return context

	En pseudocodigo

		- Se redefine el get_context_data
			- Se toma el contexto
			- Se obtienen los kwargs en la variable pk
			- Se contiene en la variable el objeto de la solicitud en el que el id sea
				igual al pk definido anteriormente
			- Se crea la variable que contendra el objeto de la persona que esta relacionada
				a la solicitud (id=igual al objeto de solicitud y al atributo del id de
				la persona)
			- Si form no esta en el contexto
				- El contexto del form sera igual al contexto.form_class
			- Si form2 no esta en el contexto
				-	El contexto del form2 sera igual a la instancia de la persona del
					self.second_form_class
			- La id del contexto sera igual al pk obtenido al principio
			- Se retorna el contexto


	Ahora para el metodo post

		def post(self, request, *args, **kwargs):
			self.object = self.get_object()
			id_solicitud = kwargs['pk']
			solicitud = self.model.objects.get(id=id_solicitud)
			persona = self.second_model.objects.get(id=solicitud.persona_id)
			form = self.form_class(request.POST, instance=solicitud)
			form2 = self.second_form_class(request.POST, instance=persona)
			if form.is_valid() and form2.is_valid():
				form.save()
				form2.save()
				return HttpResponseRedirect(self.get_success_url())
			else:
				return HttpResponseRedirect(self.get_success_url())


		- Se redefine el metodo post
			- se obtiene el objeto
			- Se obtiene de los kwargs el id de la solicitud
			- Se crea la variable donde se asignara el objeto del modelo donde el id
				sea igual al id de la solicitud
			- Se obtiene el objeto de persona donde el ide sea igual a solicitud.persona_id
			- Se recoge la info del form de manera instanciada para que se sobreescriba
				el objeto. Si no se realiza de esta manera, se creara un nuevo objeto
			- Se instancia a persona
			- Si form y form2 son validos
				- Se guarda form
				-	Se guarda form2
				- Se redirige a solitud_listar
			- Sino
				- Se redirige a solitud_listar

------------------------------------------------------------------------------ 

-------------------- CREAR REGISTRO DE USUARIOS (MODELO) --------------------- 

	DJango tiene nos trae el modelo User y el form UserCreationForm, que los podemos
	utilizar importando

		from django.contrib.auth.models import User
		from django.contrib.auth.forms import UserCreationForm

	Y de la siguiente manera

		class RegistroUsuario(CreateView):
			model = User
			template_name = 'usuario/registrar.html'
			form_class = UserCreationForm
			success_url = reverse_lazy('mascota:mascota_listar')

	Este modelo, y este form, dependiendo de la version que se este utilizando de
	DJango trae por default ciertas verificaciones. Como que las contrase#a coincida
	con su verificacion, que tenga al menos 8 caracteres con numeros, letras y otros
	caracteres permitidos, que no coincida el nombre de usuario con alguno ya guardado.

	Pero, almacena en la BD solo el nombre de usuario y la contrase#a. Dejando campos
	muy importantes de la tabla vacios, como el nombre, apellido y correo. Para
	corregir esto, podemos crear el archivo 

		forms.py

	en la app que lo utilizaremos y realizar aca las modificaciones necesarias

		from django.contrib.auth.models import User
		from django.contrib.auth.forms import UserCreationForm

		class RegistroForm(UserCreationForm):

			class Meta:
				model = User
				fields = [
					'username',
					'first_name',
					'last_name',
					'email',
				]
				labels = {
					'username': 'Nombre de usuario',
					'first_name': 'Nombre',
					'last_name': 'Apellidos',
					'email': 'Correo',
				}

	Y ahora se debe importar ese form en la vista para poder hacer uso de el, en
	lugar del form UserCreationForm

	Luego, para mejorar la vista en el template

		registrar.html

	Se utilizan las clases de bootstrap y para hacer referencia a los fields del
	contexto se coloca en el name de los inputs el nombre que tienen estos en el
	forms.py, es decir 

		first_name
		last_name
		username
		email
		password1
		password2

------------------------------------------------------------------------------ 

--------------------------- CREAR LOGIN (FACILITO) --------------------------- 

	Si del template

		base.html

	no queremos que aparezca un bloque en algun otro template lo que podemos hacer
	es escribir este bloque, pero dejarlo vacio, ejm

		{% block navbar%}
		{% endblock %}

	DJango posee una vista para realizar un login que se importa con

		from django.contrib.auth import views as auth_views

	Y realiza toda la validacion de nombre de usuario y las contrase#as

	En el curso, se utilizara el login como index. En este caso, para poder 
	utilizar esta vista como url inicial debemos configurar en el

		urls.py

	principal, la url de la vista de login luego de importarla como se dijo anteriormente

		from django.contrib.auth import views as auth_views

	Y se configurara en el urlpatterns

		path('', auth_views.LoginView.as_view(template_name='index.html'), name="login"),

	Donde se le esta pasando al metodo path como primer parametro la url de la
	cual sera llamada, luego la vista en la cual se indica directamente el template_name
	sin colocar que el

		index.html

	se encuentra en otro directorio por lo que este esta en la raiz de templates.
	El ultimo parametro corresponde al nombre con el cual llamaremos la vista mas
	adelante.

	Para indicar a donde se direccionara cuando se realice el login debemos ir al
	archivo

		settings.py

	Y configurar al final del documento la variable

		LOGIN_REDIRECT_URL = reverse_lazy('adopcion:solicitud_listar')

	Esto, luego de haber importado en settings.py

		from django.urls import reverse_lazy

------------------------------------------------------------------------------ 

-------------------------- DECORADOR LOGIN REQUIRED -------------------------- 

	Se restringiran las urls para que solo sean visibles por los usuarios logueados.

	Para poder restringir nuestrar urls vamos a utilizar un decorador que se llama
	login_requiered y se importa en el archivo

		urls.py

	de la app donde se quiere	restringir la vista con

		from django.contrib.auth.decorators import login_required

	Y lo utilizamos en nuestras urls pasandole como parametro la vista, por ejemplo
	para la app mascota

		from django.urls import path, include
		from apps.mascota.views import index, mascota_view, mascota_list, mascota_edit, mascota_delete, MascotaList, MascotaCreate, MascotaUpdate, MascotaDelete
		from django.contrib.auth.decorators import login_required

		urlpatterns = [
		    path('', index, name='index'),
		    path('nuevo', login_required(MascotaCreate.as_view()), name='mascota_crear'),
		    path('listar', login_required(MascotaList.as_view()), name='mascota_listar'),
		    path('editar/<pk>/', login_required(MascotaUpdate.as_view()), name='mascota_editar'),
		    path('eliminar/<pk>/', login_required(MascotaDelete.as_view()), name='mascota_eliminar'),
		]

	luego, cuando queramos acceder a cualquiera de los urls de la app mascota y
	no nos encontramos logueados, nos mostrara un error 404. Para que esto no ocurra y nos redireccione al login, debemos ir al archivo de urls globales

		urls.py

	y a la url del login le colocaremos accounts/login/

		path('accounts/login/', auth_views.LoginView.as_view(template_name='index.html'), name="login"),

	Solo que ahora el login dejara de ser la pagina principal de la web-app.



	Para desloguearse (cerrar la sesion) con un boton salir, vamos de nuevo al archivo
	de urls globales y de las vistas de autenticacion de DJango, las que se importan
	con

		from django.contrib.auth import views as auth_views

	utilizaremos la LogoutView configurando el url

		path('logout/', auth_views.LogoutView.as_view(), name="logout"),

	Y para que funcione, en nuestro archivo

		settings.py

	tenemos que agregar la siguiente variable, luego de la variable LOGIN_REDIRECT_URL

		LOGOUT_REDIRECT_URL = reverse_lazy('login')

	Y asi, nos desloguea y nos redirecciona al login.

------------------------------------------------------------------------------ 

---------------- RECUPERAR CONTRASEÑA POR CORREO (FACILITO) ------------------ 

	Lo primero que se debe hacer es ir al final del archivo

		settings.py

	Se deben hacer las siguientes configuraciones

		EMAIL_USE_TLS = True
		EMAIL_HOST = 'smtp.gmail.com'
		EMAIL_PORT = 25
		EMAIL_HOST_USER = 'edujpp1@gmail.com'
		EMAIL_HOST_PASSWORD = '#2205DC6fmsn'
		EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'

	Donde

		Variable del protocolo TLS
		Servicio smtp de gmail
		Puerto utilizado por el protocolo smtp
		Correo del cual seran enviados los correos
		Contrase#a del correo
		Backends del mail

	Se crearon 5 templates para cada uno de los casos que se presentan al momento
	de reestablecer la contrase#a

	1- password_reset_form.hmtl
			Contendra un input donde se colocara el mail del usuario y el boton para
			enviar

	2- password_reset_done.hmtl
			Template informativo que aparece al enviarse el mail.

	3- password_reset_email.hmtl
			Sera la vista que llegara al correo para que el usuario pueda cambiar la
			contrase#a. Este template contendra.

				Solicitaste reestablecimiento de contraseña.
				Click en el siguiente link para crear una nueva contraseña.
				{% block reset_link %}
				{{ protocol }}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}
				{% endblock %}
				Tu nombre de usuario es: {{ user.get_username }}

			donde, el bloque reset_link contendra algo muy importante. Que es el link
			que va a ver el usuario. En el link, en una variable va el protocolo, luego
			lo que seria el dominio del sitio, la url a la que va a responder y un token
			que es un token unico, que puede ser usado una sola vez para reestablecer
			una contrase#a. Esta urls es una con las que trabaja DJango.

	4- password_reset_confirm.hmtl
			Contiene un form 

				{% extends 'base/base.html' %}
				{% block navbar %}
				{% endblock %}
				{% block content %}

				{% if validlink %}

				<h1>Nueva contraseña</h1>

				<form method="post">
				{% csrf_token %}

				{{ form.new_password1.errors }}
				<label for="id_new_password1">Nueva contraseña:</label>
				{{ form.new_password1 }}

				{{ form.new_password2.errors }}
				<label for="id_new_password2">Confirme contraseña:</label>{{ form.new_password2 }}
				<input type="submit" value="Cambiar mi contraseña" />
				</form>

				{% else %}

				<h1 class="text-center">ENLACE INVÁLIDO: ESTE ENLACE YA HA SIDO UTILIZADO</h1>

				{% endif %}

				{% endblock %}

				en el cual se llama al atributo new_password1 y new_password2. Toda la
				vista de DJango se encarga de hacer todo el proceso de la validacion de
				la contrase#a. De de levantar los errores, que se hace con errors

					form.new_password1.errors

				El tag

					{% if validlink %}

				Se encarga de verificar que el link no haya sido utilizado.

	5- password_reset_complete.hmtl
			Muestra un mensaje que nos indica que ya se reestablecio la contrase#a y
			posee un boton que nos redirecciona directamente a la pagina del login.



	Para que todo esto funcione debemos configurar las urls globales en el archivo

		urls.py

	Se importa

		from django.contrib.auth import views as auth_views

	Y configurar las urls

		path('reset/password_reset', auth_views.PasswordResetView.as_view(template_name='registration/password_reset_form.html', email_template_name='registration/password_reset_email.html'), name="password_reset"),

			En esta url ademas de indicar cual es el template, tambien debemos indicar cual es el template del email. Es decir, el que se enviara al correo

	  path('reset/password_done', auth_views.PasswordResetDoneView.as_view(template_name='registration/password_reset_done.html'), name="password_reset_done"),

	  path('reset/<uidb64>/<token>/', auth_views.PasswordResetConfirmView.as_view(template_name='registration/password_reset_confirm.html'), name="password_reset_confirm"),

			<uidb64>/<token> -> haran que la url sea unica y solo pueda ser usada 1
				vez

		Es importante colocarles un

			name

		porue las vistas de DJango van a buscar esas urls y es super importante que
		los nombres de las urls los coloquemos tal como estan.


	Si vamos a utilizar un correo

		gmail

	Se debe ir a las configuraciones de la cuenta en la seccion de inicio de
	sesion y seguridad o acceso y seguridad
	y activar el permiso para el acceso de aplicaciones menos seguras.

------------------------------------------------------------------------------

---------------------------- SERIALIZAR OBJETOS ------------------------------

	La serialización (o marshalling en inglés) consiste en un proceso de codificación
	de un objeto en un medio de almacenamiento (como puede ser un archivo, o un
	buffer de memoria) con el fin de transmitirlo a través de una conexión en red
	como una serie de bytes o en un formato humanamente más legible como XML o JSON,
	entre otros.

	Serializaremos los objetos de nuestros modelos, para posteriormente poder consumirlos
	como un servicio web.

	Primero utilizaremos los serializer que nos trae DJango y luego un parquete
	que se llama Restframework.

	Importando

		from django.http import HttpResponse
		from django.core import serializers

	Podemos realizar una vista basada en funcion que nos muestre todos los objetos
	que existen de un modelo en forma de json

		def listado(request):
			lista = serializers.serialize('json', Mascota.objects.all())
			return HttpResponse(lista, content_type='application/json')

	tambien, modificando la segunda linea, lo podemos indicar que campos del modelo
	queremos que se vean

		lista = serializers.serialize('json', Mascota.objects.all(), fields=['nombre', 'sexo'])

------------------------------------------------------------------------------ 

--------------------------------- PAGINACION ---------------------------------

	Vamos a paginar utilizando ListView. Lo realizaremos en el template mascota_list.html
	con la vista

		class MascotaList(ListView):
			model = Mascota
			template_name = 'mascota/mascota_list.html'
			paginate_by = 2

	Con el paginate_by se indican la cantidad de objetos del tipo mascota que queremos
	que se vean.

	Luego en el template agregamos los botones
	
		<ul class="pager">
			<li>
				{% if page_obj.has_previous %}
					<a href="?page={{ page_obj.previous_page_number }}">Anterior</a>
				{% endif %}
			</li>
			<li>
				{% if page_obj.has_next %}
				<a href="?page={{ page_obj.next_page_number }}">Siguiente</a>
				{% endif %}
			</li>
		</ul>
	
	Donde en las tags if se indica que si el objeto de las paginas (page_obj) tiene
	un anterior o un siguiente, se redirecciona al url dinamico enviando el parametro
	get, que viene siendo

		?page=

	y se pasa la variable que vendria siendo la pagina luego del igual

------------------------------------------------------------------------------

----------------------- RESTFRAMEWORK MODELSERIALIZER ------------------------

	El Django Restframework es un paquete que nos facilita la creacion de APIs


	Se instala por medio de pip

		pip install djangorestframework


	Para utilizar el paquete crearemos un nuevo archivo dentro de la app usuario

		serializers.py

	en donde vamos a  importar

		from rest_framework.serializers import ModelSerializer
		from django.contrib.auth.models import User

	Y crearemos la clase

		class UserSerializer(ModelSerializer):

			class Meta:
				model = User
				fields = ('firs_name', 'email')

	Luego, crearemos una nueva vista en la app usuario luego de importar

		import json
		from rest_framework.views import APIView
		from django.contrib.auth.models import User
		from apps.usuario.serializers import UserSerializer

		class UserAPI(APIView):
			serializer = UserSerializer

			def get(self, request, format=None):
				lista = User.objects.all()
				response = self.serializer(lista, many=True)

				return HttpResponse(json.dumps(response.data), content_type='application/json')

	Pseudocodigo de la clase

		- Definicion de la clase que hereda de APIView
			- Se indica en que serializador se basara

			- Se sobreescribe el metodo get
				- Se crea una lista que contenga todos objetos del modelo User
				- Se serializa la lista en la variable response, colocando en true que
					habran varios objetos

				- Se retorna un json que contendra lo que existe en response	

------------------------------------------------------------------------------