CLASES DECORADORAS:

Aca tenemos un ejemplo de como se realizaba la decoracion, ahora veremos como funciona una clase
decoradora:
el metodo call es como la funcion decoradora que esta dentro de la funcion decorador en la
parte de arriba que esta comentado.
 DJANGO
Orientado al BACK-END.

- Modelo-Vista-Template.

ENTORNOS VIRTUALES:
Encapsulaciones/aislamientos de dependencias.

Por ejemplo si estoy trabajando en un poryecto de django 1.10 y me contratan para darle
soporte a una version de django 1.8, entonces si tubiera django de manera global tendria que
desinstalarlo y instalar la version que necesito para darle soporte, entonces este proceso es
tedioso, por ello nace lo de entornos virtuales que esta representada por una carpeta la cual
se le instala las librerias/ paquetes que queramos usar y solo existiran en esta carpeta
siempre y cuando este activado el entorno, si esta desactivado o estamos fuera de esta
carpeta seria como si no existiera.
INSTALACION:
1. Necesito PYTHON, se descarga el instalador desde la pagina oficial.

Comporbar que esta instalado:

python –version
 2. Instalar Django

La documentacion es muy completa y detallada y ofrece guia inicial para entender como
funciona.
Es bueno tener a la mano la documentacion.

3. Editor de codigo (sublemText, pycharm, atom, VSC..etc)

4. Crear entorno virtual para comenzar a trabajar con django, lo primero es que toca
instalar una libreria o dependencia llamada “virtualenv” la cual nos permitira crear
estos entornos.
Pip: es un gestor de paquetes en linux si se una una version 3 de python es pip3.
Para instalar “virtualen” solo colocamos lo siguiente:

en linux seria:

para verificar los paquetes instalados en el ordenador ya sea en el entorno virtual o de

manera global el comando es :
“pip freeze”

5. lo recomendable es crear una carpeta que diga entornos y poner ahi todos los
entornos.
Para crear el entorno solo colocamos el siguiente comando:
 en donde “virtualenv nombre_entorno”
NOTA: virtualenv debe que estar en el path para
que reconosca este comando.

Estas son las carpetas que se crean al crear el entorno.

La carpeta que nos interesan es la carpeta scripts en la cual hay scripts que nos
permitiran activar y desctivar el entorno virtual.
Entonces me dirijo a esa carpeta y coloco “activate”:

y aparecera el nombre del entorno que se activo, esto indica que el entorno esta
activado.
Las dependencias que estan en el entorno solo estan para el, entonces se instalo
antes virtual env de manera global si hago dentro de mi entorno pip freeze no vere ese
paquete porque dentro de mi entorno (aislado) no tengo esto.

Asi se desactiva.

6. Ya se puede instalar django:

si lo dejo de esta forma me instalara la ultima
version de django disponible.

Para indicar la version se colocan “==”

el otro paquete biene siempre y cuando instale django.

“lib/site-pakage/” dentro de el entorno creado esta esta ruta en la cual encontrara
paquetes los cuales son las librerias instaladas.
CREAR PROYECTOS (EXPLICACION DE
ESTRUCTURA BASE DE PROYECTO):
Ahora despues de que alla activado mi entorno me dirijo a un carpeta no importa donde este
ubicada si esta fuera o dentro de mi entorno

me situo sobre ella en la terminal y para crear un proyecto (el proyecto que se creara
inicialmente es una biblioteca que usaran para explicar este framework).

El comando para crear un proyecto de django es “django-admin startproyect

nombre_proyecto”

la estructura del proyecto es la siguiente:

el archivo “manage.py” es de los mas importantes que tiene todo proyecto django y el cual
debemos recordar y debemos conocer siempre porque este funciona como intermediario,
porque es a traves de este archivo que vamos a ejecutar comandos propios de django para
crear por ejemplo superUsusriaos..etc.
Ahora si vemos la linea 6 en esta se define las configuraciones que tinene nuestro proyecto y
al nosotros acceder o ejecutar comandos a traves de este archivo le decimos que django
reconosca estas configuraciones y las tome para ejecutar lo que allamos indicado.

Ahora la carpeta que aparece ahi al mismo nivel de manage.py es a la que hace referencia
la linea 6 donde dice “biblioteca.settings”, que es elmodulo de configuracion que tinen django
por defecto, y que si queremos cambiar la configuracion de nuestro poryecto es alli donde lo
debemos cambiar.

Dentro de esa carpeta se encontraran 4 archivos:

• __init__py: este archivo lo que

hace es basicamente un
indicardor por eso esta en
blanco, toda carpeta que se cree
en django para hacer reconocida
como tal y que pueda ejecutarse
y reconosca los archvos que
tinen dentro debe tener un
indicador, este indicador le
permite django saber que alli hay
scripts de python y que pertenecen al proyecto. Si este archivo no existe no reconoce
estos archivos y esa carpeta y aparecera como si no existiera.

• settings.py: es al que hace referencia la linea 6 donde dice “biblioteca.settings”.

Este archivo settings son las configuraciones que tiene django como tal para este
proyecto. Aqui hay ciertas caracteristicas como por ejemplo como fue generado y la
version de django que se puede observar en la linea 4.
 ◦ el “import os” permite
acceder al sistema
operativo donde se esta
ejecutando el proyecto
para indicarle la ruta donde
esta el proyecto y los
archivos que estan dentro
de el

• ahora en la linea 23 el
“SECRET_KEY” es unica en
cada proyecto es usada en
produccion y es secreta (ni se
comparta ni borre).

◦ “DEBUG=true” nos indicara los errores que se encuentren como por ejemplo que
no pueda acceder a una pagina o algo. En produccion debe ser false.

◦ “ALLOW_HOST[ ]” son los host permitidos, cuando lo subimos a produccion es

aqui que le debemos indicar las ip o el dominio para poder acceder al proyecto
sino se coloca mostrara error y y no se podra acceder al proyecto.

◦ “INSTALLED_APPS” : Una
aplicacion es una
abstraccion es decir si yo
tengo un rpc( modulo
contabilidad,
administracion..etc) django
toma el concepto de
aplicacion como cada uno
de estos submodulos que
tienen todo el proyecto
como tal (para separar la
logica (logica de inventario/
logica de administracion), se
pueden comunicar entre si.
Las que muestra ahi ya son
aplicaciones propias que
bienen integradas en django
y que son necesarias para
que funcionen.

◦ “MIDDLEWARE”: son la seguridad, lo que envie del servidor asi al cliente y

viseversa.

◦ “ROOT_URLCONF”: este es donde tenemos las rutas principales de nuestro

proyecto.
 ◦ “TEMPLATES”: esta
estructura es para las
plantillas y ahi ya hay
una configuracion,
django trae con sigo un
sistema de plantillas
integrado que es:

django soporta otro sistema de

plantillas.

Disr: dice los directorios y es alli donde indicaremos todos los templates del proyecto.
app_dirs: en true indica que cuando el cliente haga peticion de un template (archivo html)
django lo buscara automaticamente en todo el proyecto pero incluira la busqueda en las
aplicaciones que mencionamos solo si esta enverdadero, sino esta en verdadero no agregara
esa busqueda.

Options: son las opciones para el procesado de los templates.

• “WSGI_APPLICATION” : esto es para produccion y es la manera como se le indica

al servidor como puede levantar la aplicacion y como puede resivir las
comunicaciones.
Aca accede al archivo wsgi.py y dentro de este archivo hay una instancia de
application:

por recomendacion no tocarlo.

• “DATABASES”: nos da el link para ver las bases de datos que soporta. Postgres,
mysql, sqlLive3 son las mas comunes y que siempre se usa.
Ahi es donde esta la configuracion por defecto la configuracion biene para sqlite3. Y
no se deba hacer nada mas, no se mueve para nada.

• “AUTH_PASSWORD_VALIDATION”: es para la validacion de password para los

usuarios ya biene algunos por defecto, aca por ejemplo esta que el password no
puede ser el mismo que el nombre de usuario. Si uno escribe por defecto muestra
el mensaje. O por ejemplo el tamano sea 8 o passwords muy sencillas.

◦ “internacionalitaion”: po defecto biene en ingles US y ahi se le puede cambiar

por la que deseemos:
por ejemplo aqui le
indicamos el espanoo
de peru.
 • “static files”: son los archivos css, Js y images ahi dice como configurarlos.

Esta es la ruta en donde buscara esos archivos.

• Urls.py:

aqui estan las rutas del proyecto.

 Path es la vista que tiene incorporadas de manera interna el proyecto, todo archivo url
debe tener el urlpattern.

path() recibe lo qu se escribiria en el navegador seguido de la vista o funcion que

contendra la logica.

• Wsgi.py:

cuando se este en produccion en este archivo y en manage.py deben tener el mismo archivo
de configuracion o sino no va a funcionar.

CREAR APLICACION DE PROYECTO 2:

para explicar el modelo vista template, aca el concepto de aplicacion no se usa, las
aplicaciones nos ayudan a la abstraccion de nuestro proyecto, esto quiere decir que en la
biblioteca se tinenen diversos libros con diversos atributos representados en una tabla de la
base de datos, todo esto lo podemos centralo en un archivo y manejar su configuracion,
adicional a esto tenemos otros archivos donde tenemos el codigo que se va a seguir para
realizar el CRUD, pero tambien se tienen otros casos de anilis de la base de datos, puede
exitir una tabla usuario, que representa un cliente, se pueden tener otros administradoes,… y
se va a generar una jerarquia, esta jerarquia va a ser representada en codigo pero en
muchos casos tenemos que estar creadno archivos por archivos y se va estar creando algo
un poco complejo y por eso puede que no se separe bien la logica, para eso es que estan
creadas las aplicaciones, una aplicacion es una carpeta que tienen ciertas cantidades de
archivos los cuales estan separadas y han sido creados especificados en sus nombres para
trabajar la distinta logica que queremos representar, y cada aplicacion puede representar una
seccion de la base de datos; por ejemplo un libro su registro y campos y toda la logica para
prestamo, eliminacion..etc estaran agrupadas en una carpeta pero si necesitamos agregar la
ceracion de usuarios, administrador, podriamos tener otra carpeta que seria otra
aplicacion/subcodigo separado mas organizado (se sabe a donde ir al modificar una cosa)
para eso son las aplicaciones y eso es a lo que nos referirnos a la manera de trabajar con
django.

Para crear aplicaciones hay dos maneras:

 • La primera es crearlas de manera directamente en la raiz de nuestro proyecto a travez
del archivo manage.py.
• Y la otra manera y que recomienda para que exista un mayor orden es crear una
carpeta llamada apps y en esa meter todas las aplicaciones que se quieran trabajar.
Asi se tendra un mayor orden y se tendra separadas de la carpeta principal.

Para poder crear una aplicacion hay dos comandos uno es usando el manage.py pero que
no nos ayudara en este caso porque tenemos que estar en la ruta del manage.py y la ruta en
este caso esta en la carpeta apps:

entonces para ello se pueden crear aplicaciones con otro comando que ya hemos usado.
Primero nos dirijimos a la carpeta apps y el comando es “django-admin startapp
nombre_aplicacion”:

aca ya tendria mi aplicacion

creada.

Algo que se recomienda es que cada vez que queramos una aplicacion debemos registrarla
en nuestro archivo de configuracion “settings.py”

en installed_apps, entonces cada aplicacion

que creemos debemos agregarlas aqui.
Una vez tengamos esto revisaremos los archivos que contine esa aplicacion

si se observa veremos 6 archivos, y una carpeta llamada

migrations(aca se guadaran los archivos cuando
creemos una migracion), una migracion hace referencia
cuando nosotros mandamos una estructura/tabla creada
con sintaxis de python a nuestro gestor de base de
datos(mandar esa estructura para que se cree en
nuestra base de datos).

• admin.py: este es un archivo donde vamos a registrar modelos es decir donde vamos
a registrar modelos es decir tablas para que sean anadidas al administrador que
biene incorporado django.

• Apps.py: hace referencia a la aplicacion con su nombre nativo hay se importa la

configuracion de una aplicacion y esta enlazada por el name, si cambiara el nombre
no podria reconocer la carpeta.

• Models.py: es donde vamos a crear lo que se denomina un modelo (un modelo es

una clase hecha en python pero que esta clase va a representar a una tabla en la
base de datos (si yo tenfo una tabla llmada persona que tienen como campos
nombre, appelido, edad cada uno de los atributos sera una variable aqui en python) y
van a ser instanciados como objetos y van a crearse con sintaxis de python sin tener
 que usar SQL, para hacer esta creacion de tablas) . Este archivo iran todas las tablas
que vamos a tener y que deseamos que existan en nuestra base de datos.

• Test.py: django trae incluido codigo para hacer pruebas(test) para hacer testeo de
nuestra aplicacion (por ejemplo de nuestros modelos/tablas que esten creados
correctamente y tambien testeo de la logica de programacion que hallamos aplicado
por ejemplo la creacion de un libro si esta bien codificado y no tenemos un error.

• Views.py: aca es donde va a ir la logica y aqui es donde se separa del M-V-C, aqui la
vista no es la parte visual. En este view va a ir la logica de la aplicaion, va atener
reflejada la logica de la creacion de un libro..etc.
MODELO-VISTA-TEMPLATE:
entonces tenemos un usuario el cual va a tener una interaccion con la interfaz/pagina web o
en el sitio creado con django esta va a ser capturada por una URL (es una url que se crea en
el protecto) esta URL va a estar conectada con la vista pero a diferencia del modelo vista
controlador, esta vista lo que va a tener el codigo que va a servir para recibir la interaccion
que el usuario ha hecho y va a tener asociado un modelo ya que a traves de la interaccion y
el codigo de la vista esta indicado si se desa hacer una actualizacion, recuperar datos o
eliminar algo de la base de datos, al estar conectadoi con el modelo el modelo interactua con
la base de datos y esta interaccion al retorno de lo que recibe el modelo se lo va a pasar a la
vista y la vista tendra configurada ademas de que hacer tendra configurada donde lo va a
mostrar, la vista mandara lo que ya recibio del modelo lo va a mandar a un template y en ese
template se define como se va a apreciar todo y en este template es el que le llega al usuario
y que el usuaio ve:

en la vista tenemos la logica de programacion y en la vista tenemos asociado donde es que

se va a mostrar pero no como, el como se pone en el template que es el que interactua con
el usuario.

CREACION DE MODELOS:
los modelos es la representacion de las tablas en la base de datos pero estos estan
representados a trabes de sitanxis de python y del framework de python.
Los modelos se vana basar en clases y estas clases van a ser la representacion de las
entidades, tablas de las bases de datos.
En la documentacion de python esta la forma de crear estos modelos:
LINK:
https://docs.djangoproject.com/en/3.2/topics/db/models/

aca se muestra como se crean los diferentes campos que hay para los distintos tipos de
datos que existen y sus equivalencias en sql (lo que escribimos en python como seria en sql).
Ahi tiene las opciones y como se componen (todo esta en la documentacion).

----------------------------------------------------------------------------------------------------------------------------
Ahora vamos al archivo de settings.py y ahi se hara lo siguiente como ya se tiene
configurado sqlite3 y la idea es entender django y no lo de base de datos. Se puede usar
esta base de datos y no se neceita configurar nada.
----------------------------------------------------------------------------------------------------------------------------
Entonces ahora nos vamos al archivo models.py de nuestra aplicacion ya que es aqui donde
se debe escribir los modelos de nuestra aplicacion entonces el primer modelo que se creara
es el autor, haciendo referencia a los autores que tienen los libros, entonces el autor es una
tabla, entonces este heredara “models.Model” ya que es este archivo el que tiene la
identificacion, una clase que hereda de esta va a ser tomada por django como una tabla
(para su posterior migracion a la base de datos).

Entonces para representar a los atributos:

primero veamos como poner la llave primaria (si no le colocamos nada django le pondra una
automaticamente sera de tipo incremental y con nombre id).
Si nosotros queremos crear una llave primaria automatica y no queremos que se llame id lo
podemos hacer o si deseamos poner otra clave primaria.

Entonces por ejemplo si quiero una llave primaria autoincremental puedo ponerle por
ejemplo: models.
 “models.” es donde se
encontraran los distintos
tipos de datos.

De esta forma ya tendriamos nuestro campo autoincremental y seria nuestra llave primaria.
Ahora querems poderle un tipo, descripcion, nacionalidad.

ChardField es como el varchar en la base de datos, el parametro blank cuando registremos

un autor este campo pueda ser dejado en blanco y no bote ningun error, y null que pueda
recibir valores nulos.

Estos son otros de los muchos campos que se pueden

usar. Y ademas exiten otros parametros muchso mas
complicados.

Ahora despues de creado mi modelo la idea es que el modelo se cree en la base de datos,
para crear esto en la base de datos debemos ejecutar dos comandos estos comandos:

• el primero lo que hara es crearnos un archivo identificando los modelos que existen en
todo proyecto y dejando una estrucutra que va a ser convertida posteriormente cuando
ejecutemos el otro comando en codigo SQL y representado y aplicado en la base de
datos “python manage.py makemigrations”

se creara la cache correspondiente.

 entonce vemos que se ha creado el archivo y esta es la estructura que toma django
para convertirla en codigo sql y meterla en la base de datos.

• Lo siguiente es ejecutar el siguiente comando para que todo esto se aplique y se

convierta y ya este en la base de datos. Entonces se debe escribir “python
manage.py migrate”

entonces aca no solo creara la clase autor, porque django trae consigo ya preparado
varios modelos uno de ellos es el modelo usuario y es porque django ya tiene
preparado una jerarquia de usuarios ademas nos trae tablas con los permisos que
pueden tener estos usuarios; Y tambien se tiene que saber que django va a crear
automaticamente permisos para aplicaciones.
Ahora ya tenemos los cambios aplicados, ahora para comprobar que ya esta y en este caso
que esta con sqlite3 desde django podemos ver si en verdad esta, para verlo django nos da
una herramienta el cual es el administrado django.
Para acceder a esta administracion lo primero que necesito es un servidor para levantar el
proyecto pero no se instalara nada porque django tine su propio server:
“python manage.py runserver”

por defecto lo levanta en el puerto 8000, uno le puede cambiar el puerto “python manage.py
runserver 0.0.0.0:8006” - “python manage.py runserver 0:8006”

y al dar enter aparecera que no hay ningun error:

y aparecera lo siguiente:

esto incluira que

aparesca esta pagina
si debug es true.

Si ponemos “localhost:8000/admin”
se debe crear un ausrio para
acceder a esto:”python
manage.py createsuperuser”
CONFIGURAR POSTGRESQL CON DJANGO:

CONFIGURAR MYSQL CON DJANGO:

SITIO DE ADMINISTRACION DE DJANGO:

El administrador django es toda una interfas creada con logica propia, da panel de
administracion, se pueden hacer un CRUD de usuarios aca mismo.

Un grupo

los permisos ya
bienen definidos,
django cuando se
crean los permisos
django lo que hace
es anadirle a ese
modelo tres permisos
(el primero es
cambiar, el segundo
modificar y tercero
eliminar ese modelo).
u autor puede ser liminado y modificado y agregado por un usuario llamado:
“supervisor”. Para esto sirven estos grupos.

Usuarios:
para saber que el modelo existe de verdad.
Para saber que sea visible en esta pantalla cada vez que se agreguen:

para registrarlo solo es ir al archivo admin.py luego de esto importamos el modelo de autor y
para registrarlo se hace lo de la linea 4.

al guardar el servidor se actualiza automaticamente, y si hay un error nos mostrara eso.

 Y nos aparecen
los campos que
se colocaron en
la descripcion
de la clase.

Ahora la clase Meta indica metadatos, datos extra que se le agreguen al modelo, en este
caso se le agregara datos para como se deberia mostrar en la pagina principal:

el nombre de los atributos es

un verbose_name.

Aca cuando crea algo, lo que esta

creando es un objeto.

Para cambiar y que no aparesca de esta

forma en el modelo se escribe lo
siguiente:
el metodo self es la forma como se identificara cada objeto que se instancie.
Ahora si queremos que este organizado nuestro objeto de forma alfabetica le colocamos
lo ordenara por el
nombre.

RELACIONES EN MODELOS:
uno a uno, uno a mucho y muchos a muchos, para crear las relaciones veremos un ejemplo
con autor y libro y como crear esas relaciones.

Una relacion uno a uno se veria de la siguiente forma:

solo seria necesaria la linea de codigo 23, en donde se indicaria la relacion que se genera y
sobre que clase es que existe esa relacion, aca un libro tiene un autor y un autor tiene un
libro.
Ahora si hicieramos la migracion arrojaria un error, porque le hace falta un parametro el cual
es on_delete en donde se le indica que en caso de eliminar el elemento se borre el otro
tambien de la otra tabla:

si queremos ver como funciona esto en podriamos verlo desde el administrador.

Acordarse de agregarlo a admin y hacer la migracion.

Uno a muchos:
un autor puede tener varios libros y un libro solo puede tener un autor, para indicarle esto se
coloca:

el foreignKey() de la linea 23.

Muchos a muchos:
cuando un libor tiene muchos autores y un autor tiene muchos libros.

Solo tendria que colocar ManyToManyField y la clase con la que tiene relacion, aqui ya no
debo colocar el otro parametro.

----------------------------------------------------------------------------------------------------------------------------
fecha de creacion:

el auto_now hace que se anada cada vez que se haga una creacion o modificacion, se
actulizara con la fecha actual
EL ARCHIVO FORMS:
Ahora se va a realizar un CRUD.
Django ya trae con sigo un codigo para realizar un CRUD, eso lo podemos ver en la parte de
administracion, pero yo no tengo accesibilidad a estas funcionalidades. Para ello se debe
crear un codigo para que realicen estas acciones.

Entonces dentro de la aplicacion se creara un archivo llamado forms.py, django nos ahorra
trabajo para crear un objeto, sabemos que para la creacion se usa un formulario estos
formularios son los que hacemos en el HTML.
Pero django trae una ayuda que nos crea un formulario por nosotros y nosotros o tengamos
que crear todo eso. Entonces djnago trae una clase que ayuda a esto y se llama forms:

entonces en este archivo voy a crear una clase que me va a representar al formulario
correspondiente a cada moledo al cual le quiero realizar un CRUD.
Para nombrar las clases pertenecientes a cada moleta se va a usar una convecion “class
ModeloForm(forms.ModelForm)” recibira una herencia de ModelForm(se van a heredar los
campos del modelo y no se tocara crear exactamente los campos como si fuera un formulario
nuevo), puede ser tambien de solo form.

Ahora se va a definir otra clase dentro de esta que se va a llamar Meta esta clase hace
referencia a los metadatos que se van a manejar en el formulario, es importante definirla
porque en ell a va a ir algo que nos va a ahorar codigo:
un parametro es model = y va a ser referencia al modelo que pertenecera este form, se debe
importar el modelo, como se importar de una misma carpeta se antepone el .
Ademas del model se le debe anadir el field este hace refencia todos los campos rellenados
cuando se cree un autor (es decir los campos que se deben agregar, por ejemplo el id no se
deberia tener porque este se crea solito) entonces en esta lista iran los campos que deben
ser llenados para crear el autor:
ENLAZAR URLS DE APLICACION CON URLS DE
PROYECTOS:
Ahora veremos la parte de URLs y el archivo views, para comenzar a realizar el CRUD, lo
que se hara es enlzar la aplicacion libro y el archivo de url principal del proyecto:

para hacer esto y no tener todas las urls, en este archivo, lo que se hace es que cada
aplicacion va a tener su propio archivo de URLs y es ahi donde tendre las URLs
pertenecientes a esa aplicacion:

porque debe enlazar este arhivo de urls, con el archivo de URLs de todo el proyecto, para
hacer esto la manera de hacerlo es de la siguiente forma:
entonces se debe importar include, como se ve en la linea 17, el cual me permitira incluir
archivo o archivos URLs pertenicientes de mi proipo proyecto o externas, y ahi vemos unos
ejemplos que deja el proyecto.
Ahora para hacerlo no se hara como se muestra en el ejemplo (el segundo parametro se
hara diferente porque se quiere dar un identificador a todo este conjunto de URL de la
aplicacion, en django podemos nombrar a los archivos URLs como si fueran espacios de
trabajo es decir cuando cuando quiera llamar a una URL voy a poder hacer lo siguiente: “url :
nombre que identifica al conjunto de urls de la aplicacion: y la URL especifica de la aplicacion
a acceder”

aca indica como hacerlo pero en este caso no sirve porque el name es cuando se llama a la
vista, y como yo llamo a un archivo no se puede poner de esta manera.
) sino que el segundo parametro se le pasara un tupla la cula recibira dos cosas, el primero
parametro va a ser la ruta del archivo como tal de las URLs de mi aplicacion y el segundo
parametro es el nombre que va a ser el identificador de todas estas URLs pertenecientes a
mi aplicacion libro:

linea 21.
PRIMERA VISTA, PRIMERA URL Y PRIMER
RENDERIZADO DE UN TEMPLATE:
Ahora que vimos como enlazar las URLs de la aplicacion con la del proyecto veremos
que si iniciamos el servidor nos dara un error y esto pasa porque django no reconoce el
archivo “urls.py” como un archivo de URLs que pueda usar el proyecto, esto sucede porque
la estructura de URLs en django debe tener una lista que es la que se ve a continuacion:

y el error nos dice eso que no tiene un patterns valido y que aparentemente este no existe:

lo que se hara es crear este pattern en el archivo urls.py:

y esto era lo que haci falta agregar para que la conexion se efectura por completo, ya que
django analiza el archivo indicado en la imagen arriba de esta en la linea 21, y tiene que
encontrar algo esencial que es el urlpatterns el cual debe tener la aplicacion.

Ahora para poder crear algo en el archivo de urls de mi aplicacion primero debo ir al archivo
views.py y se creara una vista sencilla para que yo cuando ingrese a una URL me pinte un
template; para hacerlo se creara una funcion, la cual recibira un parametro llamado request
que es el parametro que toda funcion debe recibir cuando vamos a trabajar con peticiones
que vengan del navegador (este parametro tendra la interaccion que hizo el usuario en el
navegador, ). esta funcion solo retornara una linea en donde se usara el metodo render que
se importa por defecto cuando se crea el modelo, el cual lo que hace es renderizar
templates, para indicarle esto recibe unos parametros, el primero es uin request que es la
peticion (porque va aa responder algo de acuerdo a la peticion que le envian), el siguiente
parametro es el template que renderizar, el template que renderizara es el que esta en la
carpeta “libro/index.html”
ahora debo asignar eso de ahi a una URL para poder obtener lo que quiero, ahora en el
archivo de urls de la aplicacion se importara home de views, y se ara lo siguiente. Path recibe
tres parametros el primero es el texto que escribira en la barra de direccion y es el necesario
para acceder que este en la funcion que se le pasa como siguiente parametro el cual es
home, cuando escribamos el texto accedera a esa funcion y ejecutara lo que este ahi, y el
ultimo parametro es el nombre identificador para toda la URL por si quiero usarlo en algun
sitio (este nombre solo es usado por plantillas django si no se usa eso ese tercer
parametro no se coloca).

Ahora sucede algo que si accedermos a la url nos dira que el template no existe, ya que el
template que se coloco en la imagen de arriba no existe asi que se debe crear el template,
ahora para estructurar los templates en mi proyecto, en la carpeta raiz se creara un folder
llamado template, dentro de cada template se creara una capeta con el nombre de cada
aplicacion, de esta forma se tendra un mayor nombre
ahora por ultimo para que funcione toca ir al archivo de configuracion donde dice templates,
ahi hay un parametro llamado DIRS que es donde van a estar nuestros templates

y se pone el nombre de la carpeta, ahora si llega a salir error se reinicia el servidor para que
coja los cambios que se realizaron.
VISTAS BASADAS EN FUNCIONES: CREAR AUTOR:
para continuar se realizaran algunos cambios. Se vera el proceso de como realizar la vista de
creacion.

Se van a realizar unos cambios en donde el index como no deberia estar en libro, ya que ese
index va a ser como el home de toda la aplicacion por lo cual se realizaran unos cambios, lo
primero es pararse en “urls.py” de la aplicacion y se importara el home que se realizo en
apps.libro.views:

y se indicara el path que tendra.

Por lo cual el archivo de url de mi aplicacion quedaria de la siguiente forma:

y en views se cambiaria la ruta que se usa en el render:

entonces este index ya no estara en libros sino se mueve a la carpeta de afuera:

entonces si se va a home aparecera lo siguiente:

----------------------------------------------------------------------------------------------------------------------------
para crear mi vista vamos al archivo de views y crearemos el renderizado de la vista de
crearAutor por lo cual crearemos una funcion con este nombre y que recibe por parametro el
request; ahora cuando interactuamos con el navegador se hace a traves del protocolo http y
este tiene unos metodos definidos para ciertas acciones que se quieran realizar. (get,
post..etc), entonces las acciones a realizar a continuacion es un metodo get el cual me
renderiza la pagina y uno de post que es cuando yo llene el formulario y envie eso.

En el crearAutor lo primero que preguntare si el request es un post en caso de cerlo se

creara una variable llamada autor_form y la igualare a una instancia de autorForm()
y este hace referencia a esta clase que se creo anteriormente y que lo que lo que aria era
crearme contenido HTML, es decir inputs y etiquetas html pertenecientes a cada uno de los
campos que se ven ahi y que se le han indicado y que pertenecen al modelo autor

entonces al instanciarlo le dire que esta instancia reciba todos los datos que se le han
mandado y esos datos estan en el request.post y ahora lo que se preguntara si los datos
enviados son correctos para poderlos guardar, para ello hay una funcion que trae los
formulario en django que es is_valid() lo que hace es validar mi formulario es decir si el tipo
ingresado en el input es igual al que tengo en mi base de datos, si no exceso los
caracteres..etc, esto se valida automaticamente, si es valido espero que mi aplicacion
registre todos estos datos en mi base de datos. Por lo cual se realizara la funcion .save sobre
la instancia creada de autoFomr y este es un metodo que tiene todo modelo que herede de
models.Model, este metodo lo que hace es registrar en la base de datos lo que se se alla
enviado en el formulario es decir lo que este en autorForm():
ahi yo ya tendria guardado en la base de datos todos los campos que realice.
Ahora luego de guardarla me redireccione a otra URL de todas las que tengo:
para ello se usa el metodo redirect el cual recibe la URL pero no se pondra la url porque ne
python las urls tienen un nombre asociado y ese es el que se pondra:

entonces esto es correcto si es enviar informacion, ahora si me llega un apeticion para cargar
la pagina de creacion en este caso el metodo seria un metodo Get entonces se instancia una
variable de autoForm() pero sin contenido para que me cree el contenido html perteneciente
a cada atributo del modelo que he realizado y esto debo retornarlo a mi template para
retornarlo debo hacer un return general de la funcion, ahora como tercer parametro lde debo
retornar el autoForm pero lo devolvere en un diccionario:
no olvidar importar autorForm ya que lo estamos usando.
----------------------------------------------------------------------------------------------------------------------------
ahora falta cerar la url para esta vista y el template:
ahora lo primero crearemos la url:

ahora crear el template:

se va a escribir una sintaxis

propia del sistema de plantillas
propia de django, pero mas
adelante se explicara como es
que trabaja y que es lo que
contiene.
Lo primero es crear el <form>
el archivo forms.py nos crea el
formulario como tal pero no
crea la etiqueta form, nos crea
lo que va dentro del form.

Ahi dentro es que se va colocar la variable que se le colocaba en views que es auto_form
que es una instancia de AutoForm().
Entonces primero en la etiqueta se le pone el metodo.
Las varibales se pintan en el sistema de plantillas de django con
{{ nombreVariable(auto_form}}, como es un formulario es pintarlo de alguna manera de las
que nos ofrece django una es con un parrafo y otra como una tabla, aca se va a usar como
un parrafo entonces se coloca {{ autor_form.as_p}} el “as_p” lo pinta como uin parrafo
(“as_table” lo pinta como tabla).
Ahora faltaria el boton de crear.

y al ir a la pagina se ve lo siguiente:

y esto es lo que realiza el autorForm(), esto me

pinta un label he input para cada campo que yo
le indique.

Ahora el crea esto con las caracteristicas que tenga mi modelo autor.
Ahora para ver que es lo que me trae autor_form le ponemos lo siguiente a la funcion
crearAutor():

se le pone el print en la linea 15, y si vemos en la terminal observaremos lo siguiente:

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

entonces al darle al boton crear saldra lo siguiente:

un error de CSRF que es una verificacion
de seguridad, que es parte de los
middlewars que tiene django incluidos, y
en la linea 47 del archivo de
configuracion ponemos ver este
middlewar
ese no permite enviar la peticion post, ya que no estamos pasando todos los datos que
tenemos, es decir hay unos datos que requiere el framework como tal para que alla un envio
seguro y esta haciendo todo seguro. Entonces para hacer la peticion post se debe realizar

algo y es lo siguiente:

con esto se solucionaria el

problema y ya podria crear el autor.

Y al crear el autor me regresa al index de la aplicacion, que fue lo que se le indico:

ahora si yo quiera crear algo, todo esto ya esta validado por

python, son unas validaciones minimas que este genera y
que vimos anteriormente.
SISTEMA DE PLANTILLAS DE DJANGO:
en el archivo de configuracion vamos a encontrar el sistema en la seccion llamada templates,
encontraremos la forma que tienen django para renderizar templates, que es por medio de
django.templates:

la otra manera que tienen dejango para renderizar es con “ginja2”, en caso de que se quiera
averiguar en la documentacion se puede encontrar.

Pero se va a dejar django.templates que biene configurada por defecto.

La filosofia de django es que no repitas el codigo que no hagas algo dos veces, entonces al
tener esta filosofia cuando escribimos HTML tendemos a repetir vario codigo qu tebe tener
toda pagina web, para horrar el trabajo escribes el template de tu pagina una sola vez y al
escribirlo una sola vez hacer que los demas templates hereden de este template base, un
template que hereda de otro tendra las caracteristicas del que hereda.

Este index sera la base y

crear autor heredara de
este index.
Para realizarlo lo primero hay que entender que es un tag:
esto es un tag y donde lo pongamos ndica que
este bloque / seccion de codgio se llamara
title, ahora despues debemos indicar donde
terminara el bloque:

de esa forma cuando yo cargue el template me cargue y el titulo siempre y cuando yo lo

coloque puedo cambiarlo por el que est apor defecto.

Entonces para heredar el template se coloca como esta en la linea 1 en donde como el
archivo index esta en la raiz del directorio “templata” por eso se importa de esa manera, otra
cosa es que cuando hereda omite todo lo que esta bajo por lo que si queremos escribir lo
quetenemos en este HTML se debe meter dentro de los tag creados
si quisieramos usar if o for dentro del template
para realizarlo es de esta form:

como si fuera codigo python pero dentro de

template.

CONSULTAS BASADAS EN DJNAGO:

antes de proceder veremos como realizar consultas en django, entonces no se usar sintaxis
de SQL puro sino usaremos un ORM (django trae el suyo propio y con sintaxis de python se
pueden crear estas consultas).

Lo primero que se realizara es ingresar a la shell de python dentro del proyecto (“python
manage.py shell”:

aca lo que se realizara es traer los modelos con los que se trabajara en este caso el de autor
y como ya se esta ejecutando la shell en el proyecto no se debe importar el archivo settings
lo que ser relizara es lo siguiente para importar el modelo de autor:
“from apps.libro.models import autor” entonces como no se va usar SQL puro, el ORM
que tiene django esta enlazado con todo modelo que creemos lo que se hace es usar un
atributo que tiene todo modelo y es “objects” el cual hace referencia a una clase llamada
objectManager, esta clase es la que se encarga de realizar la peticion y consultas a la base
de datos.

Entonces cuando se have la herencia de models.Model ahi es donde se esta incluyendo el

atributo de objects y objectManager ya que model.Model tiene dentro de su codigo
implementado el atributo objects y objectManager y por herencia tienen todos los atributos y
metodos:

Entonces por medio de este ORM si yo quiero crear un autor, llamo la clase luego el atributo
object y de este el metodo create al cual se le pasan los atributos que tienen autor, y al
ejecutarlo me devuelve el autor que cree y eso indica que quedo registrado:

la segunda manera es instanciar un nuevo objeto de autor y asi como haciamos en el archivo
views.py que poniamos la instancia he imbocabamos el metodo save:

y de esta forma queda guardado el autor.

Ahora si yo quiero obtener los valores lo hago de la siguiente manera

con all() me devuelve todos mis autores.

Ahora si yo quiero filtrar solo los que sena de peru utilizo filter()

y me trae los autores con esa filtro.

Ahora si yo quiero tambien valores para poder editarlos para hacerlo es la siguiente forma, lo
primero es que para poder editarlo solo se puede hacerlo a un solo valor de la base de datos
por lo que se llama la funcion get(), este get lo que hace es traer el dato con el filtro dentro de
este, el problema es que sino encuentra nada bota error y si trae mas de uno me genera otro
error:

ahora yo puedo filtrar por mas de un solo parametro:

la “,” funciona como un &, me trae loas autores connacionalidad de peru y id 8.

en la documentacion de django hay varias cosas que se pueden hacer dentro de las queries
y ademas cosas mucho mas complejas.

VISTAS BASADAS EN FUNCIONES, LISTAR AUTOR:

ahora hariamos la parte de listar el CRUD, ahora se va a realizar el listado, es decir mostrar
todos los autores que se vayan registrando, entonces se va crear una lista que va a recibir el
request, esta vista va a tener dos cosas, lo primero va a ser una consulta a la base de datos
trayendo todos los autores que existan en ella y lo segundo la instruccion que haga eestos
autores que trae los lleve al template y se puedan renderizar.
Esto se realiza en la vista, donde
teniamos el crearAutor. No olvidar
importar el modelo autor.

Ahora agregamos el endpoint al archivo de urls:

entonces ya se tendria la vista y la URL, y ahora solo queda crear el template que se le esta
indicando en la url:

con esto se tendria el template que lista a los autores.

Ahora solo queda probar.
PATH, REPATH: MANEJO DE URLS:
nos faltaba la parte de las URLs que era la parte de como pasar o recibir, enviar un
parametro que necesitamos para poder analizar ese parametro que biene de las URLs.
Faltaria ver como enviar los parametros en el path.

Ahora hay dos formas de crear una URL la primera es con “path” y la otra es con otra funcion
llamada “re_path” esta funcion es la manera en que se hacia antes de usar path. Con path
para pasar parametros se mete dentro <> dentro indicamos el tipo de dato a pasar y el
nombre que tiene:

slug es un string.

Asi se trabaja para los distintos parametros:

en versiones 1.11 no se existia path y re_path se trabajaba con url() t aca se trabajaba con
expreciones reculares, y se escribian de la siguiente manera:

esta era una url en blanco

y esta es la url de crear_autor.

Por ejemplo para pasar un userName se escribia de la siguiente manera:

ahora hoy en dia podemos trabajar con expreciones regulares ya que no se existe url en
django dos en adelante, esto mismo se trabaja usando re_path, entonces permite usar
expreciones regulares que se usan en django 1.11: