Apunte1.txt

-------------------------APUNTES CURSO DJANGO DJANGO-REST API ----------------------------------------------

Al comenzar el proyecto django, se crean varios archivos, entre ellos:

__init__.py  Este siempre va en las carpetas para que sirvan como librerías.

asgi.py y wsgi.py Permiten que se levante la página por defecto de django y el servidor 

settings.py Es el archivo de configuraciones de mi entorno Django, tiene muchas cosas, por ejemplo configurar el idioma.

urls.py Tambien es importante, manejará las urls disponibles del proyecto, puede tener un path que nos lleve a otra carpeta de url's
por defecto, trae la de admin, que al ingresar a la ip, que nos da runserver / admin , entramos al administrador de Django. 

Dentro de django, toda función declarada necesita llevar el argumento self. (Repasar el tema de funciones )


----------------------------------------------------------------------------------------------------------------
--------------------------SECCION 4. ENTORNOS DE TRABAJO OPTIMO CON DJANGO--------------------------------------
----------------------------------------------------------------------------------------------------------------

Se tiene que separar los entornos de testing, local y producción, cada uno tendrá sus propia configuración,
sus propios paquetes etc. y cada uno trabaja solo, pero en el mismo proyecto. El proyecto final, se traspasa a producción.
Producción, es el producto final, sin ninguna librería innecesaria. Solo lo estrictamente necesario para el producto final del software.

Todos los entornos, necesitaran el secret_key , el bloque de INSTALLED _APPS . Crearemos una nueva carpeta settings, en donde tendremos 
un archivo de configuracion para cada entorno, sin reescribir en cada uno codigo, si no escribiendo la configuracion que es compartida 
en otro archivo llamado base.py , ahí alojaremos todo lo de settings.py , que necesitemos 


---------APLICACIONES EN DJANGO (DOCUMENTACION) STARTAPP:---------

El directorio raíz de un proyecto (el que contiene manage.py) suele ser el contenedor de todas las aplicaciones 
de un proyecto que no se instalan por separado.

El término aplicación describe un paquete de Python que proporciona un conjunto de características. 
------[[Las aplicaciones se pueden reutilizar en varios proyectos.]]-----

Las aplicaciones incluyen alguna combinación de modelos, vistas, plantillas, etiquetas de plantilla, archivos estáticos, URL,
middleware, etc. Generalmente están conectadas a proyectos con la INSTALLED_APPSconfiguración y, opcionalmente, con otros mecanismos
como URLconfs, la MIDDLEWAREconfiguración o la herencia de plantilla.

Son la forma de aplicar el principio de encapsulamiento en django o algo parecido a microservicios, la idea es que cada aplicacion de django
sea independiente de las demás , de esta forma podamos reciclarlas. Imaginate, desarrolladas algunas, puedo reciclar en otros proyectos.
Por ejemplo una app que solo se dedique a busquedas, otra solo almacen, otra solo ventas etc.

Eso sí estos no son modulos, cada uno es un proyecto ya que cada uno tiene sus archivos de configuracion correspondientes y toda 
la estructura de un proyecto en django , codigo, base de datos, urls, templates , views. 

Una vez creadas las apps, dentro de la carpeta applications, debemos agregarlas a nuestro archivo base.py de configuracion en el item 
INSTALLED_APPS, sin embargo la primera direccion la reconoce ya como una aplicacion :

INSTALLED_APPS =[
'polls.apps.PollsConfig',
'django.contrib.admin', 
...
]

Por lo que la ruta applications.departament.apps , nos dará error. Para corregir esto y matener nuestro orden mediante la carpeta 
applications, quitaremos el .apps de nuestras rutas 

en vez de poner 'applications.empleados.app' pondremos : 'applications.empleados'
Pero en el archivo apps.py de empleados, en name pondremos en vez de name='empleados'  ponemos : name 'applications.empleados'

Así queda finalmente:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    # LOCAL APPS 
    'applications.departamento',
    'applications.empleados',
]

--------------------------------------------------------------------------------------------------------
---------Patrón de diseño MVT - Modelo Vista Template --------------------------------------------------
---------------------------------------------------------------------------------------------------------

Haremos pruebas con una nueva app "probes" , la agregamos al archivo de cngiracion installed_apps , le cambiamos el name en su apps.py
a applications.probe. Esta apps , como todas se crea con views.py , models.py , le crearemos una carpeta templates, dnde crearemosnuestros 
templates html , que vendrian siendo la parte que falta del mvt. El archivo apps.py es para configurar la aplicacion , el test.py para
posteriormente realizar pruebas unitarias. 

Puedo sin antes crear un modelo, solo crear un view, dependindo del tipo de clase que herede, puedo mostrarlo, 
tengo que crear un url, en urls, importar desde la carpeta del proyecto. y luego  en url quedaría algo así :

from django.contrib import admin
from django.urls import path
from applications.probes. views import IndexView

urlpatterns = [
    path('admin/', admin.site.urls),
    path('home/', IndexView.as_view()),
]


Este es el urls de proyecto, pero puedo crear un urls.py en mi app y trabajar cn estas y luego conectarlas cn la url principal.
----------------------------------------------------------------------------------------------------------------------------------------

Vamos a crear una carpeta Templates a nivel proyecto, es decir en la misma altura de la carpeta de nuestro proyecto, para desde esta reutilizar
codigo hacia los templates de nuestras apps. Vamos mis amoreee dalee. Pero alfinaaal haremos el diseño. 
Para que lo anterior funcione, debemos en nuestro archivo de configuracion base.py, agregar nuestra direccion a DIRS de TEMPLATES
de dicho archivo, esto para que reconozca los templates de nuestras nuevas carpetas, siguiendo el orden que queremos.
Quizás sea necesario editar la dirección raiz BASE_DIR, se configura en el mismo archivo, más arriba
----------------------------------------------------------------------------------------------------------------------

Para mantener el orden según lo anterior, crearemos un urls.py , para cada aplicacion, y así no llenar de urls el urls.py 
del proyceto si no que solo llamar a todo lo qe contengan también los urls.py por cada app. para los urls.py de applicaciones
copiaremos el sgte codigo, from urls of projecto , editaremos los path segun necesitemos en cada app  : 

from django.urls import path
from applications.probes. views import IndexView

urlpatterns = [
    path('admin/', admin.site.urls),
    path('home/', IndexView.as_view()),
]

--------------------------------------------------------------------------------------------------------------------
Django ofrece unn set variado de subclases de view, para realizar funcionalidades tipicas, como enlistar, login,
register, etc. cada una la podemos modificar en su uso, y agregarle cosas nuevas, con esto se ahorra muchisimo tiempo
en el desarrollo. 
---------------------------------------------------------------------------------------------------------------------
Cuando hablamos de BASES DE DATOS, hablamos de consultas: - procedimientos almacenados , - scripts , - disparadores/triggers
registros, copias de seguridad. Todo lo anterior, sin importar el motor de base de datos son SQL . 

Creada una clase en models, que herede de models, en admin.py , coniguramos que queremos interactuar con la base de datos. 
ejemplo:
--------------------------------
from django.contrib import admin
from .models import Prueba

# Register your models here.

admin.register(Prueba)


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

Para recorrer el choices, no era necesario realizar dos for anidados:

class Empleado(models.Model):
    job_choices=(('0','Contador'),
                 ('1','Administrador'),
                 ('2','Economista'),
                 ('3','Developer'))
    ''' Modelo para tabla de empleado'''
    first_name = models.CharField('Nombres', max_length=60)
    last_name = models.CharField('Apellidos', max_length=60)
    job=models.CharField('Trabajo',max_length=1,choices=job_choices)
    departamento = models.ForeignKey(Departamento, on_delete=models.CASCADE)
    
    def __str__(self):
#      for cargos in self.job_choices:  
 #      for n,cargo in cargos:
        for n,cargo in self.job_choices:  # Como se define self.job_choices , quiere decir que ya agarro una pareja ('n','cargo') la asignada. 
            if n==self.job:               # Por esto no es necesario recorrer job_choices, con dos for
             return f'{self.id}- {self.first_name} - {cargo}'
#      return f'{self.id}- {self.first_name} - cargo desconocido'    



Lo anterior quedó expresado así, para poder mostrar cuando se llame a un objeto de la clase empleado
en el administador, se verá el id - primernombredelempleado - cargo del empleado:

class Empleado(models.Model):
    job_choices=(('0','Contador'),
                 ('1','Administrador'),
                 ('2','Economista'),
                 ('3','Developer'))
    ''' Modelo para tabla de empleado'''
    first_name = models.CharField('Nombres', max_length=60)
    last_name = models.CharField('Apellidos', max_length=60)
    job=models.CharField('Trabajo',max_length=1,choices=job_choices)
    departamento = models.ForeignKey(Departamento, on_delete=models.CASCADE)

    def __str__(self):
      for n,cargo in self.job_choices:
        if n==self.job:
          return f'{self.id}- {self.first_name} - {cargo}'
  
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
--------------------ADMINISTRADOR DE DJANGO (MODULO 7)----------------------------
----------------------------------------------------------------------------------

Con un buen dominio del administrador de django podemos acelerar aún más el desarrollo 
del producto, poniendo énfasis en la lógica del negocio .

(!!!) Realizo el cambio de nombre de las clases en mis modelos a inglés, también las carpetas y todo en el proyecto a excepción de el 
contenido en la carpeta probes. Para esto se modifican los archuvos urls, view, la configuracion en local, los admin.py Y luego de 
haber modificado todo con los nuevos nombres, se eliminan todos los archivos.py dentro de las carpetas migrations de cada app. 
Sre ejecutan los comandos makemigrations y migrate satisfactoriamente, podemos seguir con el proyecto en inglés, que es la buena
práctica de desarrollo. (!!!) el comit se realizó con el comentario "change from spanish to english, and new migrations"

Para mejorar el manejo de nuestros modelos dentro del administrador de django, podemos agregar una clase Meta a un modelo.

----GEMINI: 

Los metadatos en el contexto de una clase Meta para un modelo en Django:

En Django, una clase Meta dentro de un modelo define información adicional sobre el comportamiento del modelo en la aplicación. 
Esta información se conoce como metadatos. Los metadatos no son parte del modelo en sí, sino que proporcionan información adicional 
que Django utiliza para gestionar el modelo.

Algunos ejemplos de metadatos que puedes definir en una clase Meta incluyen:

verbose_name: El nombre que se mostrará en la interfaz de administración de Django para el modelo.
verbose_name_plural: El nombre plural que se mostrará en la interfaz de administración de Django para el modelo.
ordering: Una lista de campos por los que se ordenarán los objetos del modelo por defecto.
db_table: El nombre de la tabla en la base de datos que se utilizará para almacenar los datos del modelo.
unique_together: Una lista de tuplas de campos que deben ser únicos juntos.
permissions: Una lista de permisos que se pueden usar para controlar el acceso al modelo.

Aquí hay un ejemplo de una clase Meta con algunos metadatos:

Python
class MyModel(models.Model):
    name = models.CharField(max_length=255)

    class Meta:
        verbose_name = "Mi modelo"
        verbose_name_plural = "Mis modelos"
        ordering = ("-name",)
        db_table = "my_models"
        unique_together = (("name", "age"),)
        permissions = (
            ("can_view_my_model", "Puede ver mi modelo"),
            ("can_edit_my_model", "Puede editar mi modelo"),
        )

---DJANGO DOCUMENTACION:
Los metadatos del modelo son “cualquier cosa que no sea un campo”, como opciones de orden ( ordering), 
nombre de tabla de base de datos ( db_table) o nombres singulares y plurales legibles por humanos ( verbose_namey verbose_name_plural).
No se requiere ninguno y agregarlo a un modelo es completamente opcional.class Meta

Meta Puede encontrar una lista completa de todas las opciones posibles en EL SGTE LINK:
https://docs.djangoproject.com/en/4.2/ref/models/options/

ejemplo en mi codigo :

class Departament (models.Model):
  name=models.CharField('Departament Name',max_length=30)
  shor_name=models.CharField('Short Name' , max_length=20,blank=True,null=True,unique=True)
  anulate=models.BooleanField('Anulated', default=False)

  def __str__(self):
    return f'{self.shor_name} - {self.name}'
  
  class Meta:
    verbose_name='Departamento'           # si quiero escribo esto, le cambio el nombre a como se presenta en django
    verbose_name_plural='Departamentos'  
    ordering=('name',)                #ordena las filas de la columna del campo por name alfabetico. inverso -name
    unique_together=('name', 'shor_name')  # Solo se puede registrar una combinacion de nombre y shortmname.
    # es decir la combinacion de ambos campos no se puede reptir. 


Otro caso en probes.py: 
    
class Prueba(models.Model):
  #Shields of my model
  mes=models.CharField('Mes',max_length=30)
  meta = models.CharField('Meta/s',max_length=50)
  
  class Meta:
    unique_together=('mes',)      
    #Functions of my model
  def __str__(self):
    return f'{self.mes}: {self.meta}' 

# no me deja ingresar dos veces el mismo mes.    
-------------------------------------------------------------------------------------------------------------------
Conclusión 12/03/2024

ESTAMOS INTENTANDO REALIZAR LA RELACION MUCHOS ES A MUCHOS P ARA DARLE DISTINTAS TAREAS A CASA META DEL MES. 
Se puede, sin embargo al crear una clase cn solo campo model.charfield,  y luego asociarla a la clase de mes,o meta
se puede asociar solo una tarea, a varios meses, utilizando el ForeignKey. Otro caso sería utilizar manytomany fields
pero al relacionar la lista de tareas a cualquier mes, se relacionan todas las tareas existentes. 

El mismo problema ocurre para asignarle distintas skills a un empleado, o le asigno todas las skills con manytomany, o le asigno solo 
una de las disponibleas con ForeignKey. Se debe resolver una forma de que de las distintas skills credas, de la clase Skill, se puedan
asociar a un empleado, solo las que uno determine en el administrador, y no todas o no solo una sola. 

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



AVANZANDO 14/04/2024

A continuación avanzaremos con lo que presenta el curso. el punto anterior pendiente de poder seleccionar skills
y asignar más de una a un trabajador, está pendiente. 

A continuación se editará la vista del administrador para la sección de empleados, actualmente luce así :


EMPLEO
	Carrasco- Nathalie - Developer
	Guerra- Cesar Patricio - Administrator
	Higueras Reglâ- David Jean - Developer
	Montecinos- Andrea - Administrator

  Sin entregar más información sobre cada empleado que el cargo, queremos que muestre la información de cadda empleado en una tabla.
y no solo una lista punteada.

DOCUMENTACION :

El sitio de administración de Django ¶
Una de las partes más poderosas de Django es la interfaz de administración automática. Lee metadatos de
sus modelos para proporcionar una interfaz rápida centrada en el modelo donde los usuarios confiables pueden
administrar el contenido de su sitio. El uso recomendado por el administrador se limita a la herramienta de gestión
interna de una organización. No está diseñado para construir toda la interfaz.

El administrador tiene muchos ganchos para la personalización, pero tenga cuidado al intentar utilizar esos ganchos exclusivamente. 
Si necesita proporcionar una interfaz más centrada en procesos que abstraiga los detalles de implementación de las tablas
y campos de la base de datos, entonces probablemente sea el momento de escribir sus propias vistas.

En este documento analizamos cómo activar, usar y personalizar la interfaz de administración de Django.


---ModelAdmin objects----

La ModelAdminclase es la representación de un modelo en la interfaz de administración. 
Por lo general, estos se almacenan en un archivo nombrado admin.pyen su aplicación.
Echemos un vistazo a un ejemplo de ModelAdmin:

___________________________________
from django.contrib import admin   # viene por defecto en admin.py de la appcreada
from myapp.models import Author    # Importamos un modelo desde los modelos de nuestra app , models.py , en este caso Author

class AuthorAdmin(admin.ModelAdmin):
    pass

admin.site.register(Author, AuthorAdmin)  # Para poder visualizar nuestro modelo en admin ,debemos registrarlo cn esta linea   
___________________________________
¿ Necesitas ModelAdminalgún objeto?

En el ejemplo anterior, la ModelAdminclase no define ningún valor personalizado (todavía). Como resultado, 
se proporcionará la interfaz de administración predeterminada. Si está satisfecho con la interfaz de administración predeterminada,
 no necesita definir ningún ModelAdminobjeto; puede registrar la clase de modelo sin proporcionar una ModelAdmindescripción.
  El ejemplo anterior podría simplificarse a:
_______________________________
from django.contrib import admin
from myapp.models import Author

admin.site.register(Author)
________________________________

ModelAdmin options¶
Es ModelAdminmuy flexible. Tiene varias opciones para personalizar la interfaz. 
Todas las opciones están definidas en la ModelAdmin subclase:

---
from django.contrib import admin


class AuthorAdmin(admin.ModelAdmin):
    date_hierarchy = "pub_date
---
ModelAdmin.fields¶
Utilice la fieldsopción para realizar cambios simples en el diseño de los formularios en las páginas «agregar» y «cambiar», 
como mostrar solo un subconjunto de campos disponibles, modificar su orden o agruparlos en filas. Por ejemplo, podría definir una
 versión más simple del formulario de administración para el django.contrib.flatpages.models.FlatPagemodelo de la siguiente manera:

class FlatPageAdmin(admin.ModelAdmin):
    fields = ["url", "title", "content"]


En el siguiente link ,están todos los atributos que se pueden editar para la subclase ModelAdmin
https://docs.djangoproject.com/es/4.2/ref/contrib/admin/
En ella se ven varios atributos , para personalizar nuestos paneles de administrador.
Las posibilidades son muchas, los atributos tienen de todo. 
Un atributo muy útil es list_filter 
También contiene un monton de métodos, revisar más tarde. 

También está la clases: InlineModelAdmin, adminsite , con muchos objetos:

AdminSite.login_template¶
Ruta a una plantilla personalizada que será utilizada por la vista de inicio de sesión del sitio de administración.

FIN DOCUMENTACION


El problema de poder distinguir entre las skills disponibles para todos y las disponibles de ese grupo 
para cada empleado, se solucionó con un filter_horizontal , con este escogo cuales de la lista de ksills
posee mi empleado. además puedo agregar skills a filter general del panel y filtrar trabajadores
segun las skills que posean. !!

FUNCION ESPECIAL : 

Puedo agregar una columna, con un campo que no esté definido en models, pero debo enseguida
definir su contenido mediante una función, con esto puedo hacer mucho, cálculos quizás, sacar conclusiones
a raíz de otros campos del modelo, por ejemplo con la fecha de nacimiento, calcular la edad. 


ejemplo :

class EmpleadoAdmin(admin.ModelAdmin): 
  list_display('first_name','job','full_name',)
   
   def full_name(self,obj):
   print(obj.first_name)
   return obj.first_name + ' ' + obj.last_name

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

Otra cosa que se puede hacer en el admin de django, es personalizar el frontend del mismo. 
Se puede utilizar apps de terceros, con distintos fines, que crearon en la ocmunidad de Django. 
Por ejemplo, un editor, que agrege una ventana un campo para editar texto, se puede haceer qe puedas cargar imagenes, 
y otras cosas, el estilo del mismo administrador. Uno weno es DJango CKEditor
Hay algunas apps de terceros que sirven al admin, otras no. 

fin por 15/03 , Para el 16/03 comenzar a trabajar con las vistas genéricas de Django. 

----------------------------------------------------------------------------------------------------------------
------------------------------------------------------------
16 MARZO -----------------------------------------------------

Sección 8: Vistas basadas en Clases de Django. 

DOCUMENTACION :Vistas de escritura ¶

Una función de vista, o vista para abreviar, es una función de Python que recibe una solicitud web y devuelve una respuesta web. 
Esta respuesta puede ser el contenido HTML de una página web, una redirección, un error 404, un documento XML o una imagen. . . o
cualquier cosa, de verdad. La vista en sí contiene cualquier lógica arbitraria necesaria para devolver esa respuesta. 
Este código puede vivir en cualquier lugar que desee, siempre que esté en su ruta de Python. 
No hay ningún otro requisito, no hay «magia», por así decirlo. Con el fin de colocar el código en algún lugar ,
la convención es colocar las vistas en un archivo llamado views.py, ubicado en el directorio de su proyecto o aplicación.


Una vista sencilla¶

Aquí hay una vista que devuelve la fecha y hora actuales, como un documento HTML:

from django.http import HttpResponse
import datetime


def current_datetime(request):
    now = datetime.datetime.now()
    html = "<html><body>It is now %s.</body></html>" % now
    return HttpResponse(html)

Repasemos este código una línea a la vez:

Primero, importamos la clase HttpResponsedel django.httpmódulo, junto con la biblioteca de Python datetime.

A continuación, definimos una función llamada current_datetime. 
Esta es la función de vista. Cada función de vista toma un HttpRequest
 objeto como primer parámetro, que normalmente se denomina request.

Tenga en cuenta que el nombre de la función de vista no importa
; No es necesario que tenga un nombre determinado para que Django lo reconozca. 
Lo llamamos current_datetimeaquí porque ese nombre indica claramente lo que hace.

La vista devuelve un HttpResponseobjeto que contiene la respuesta generada. Cada función de vista es r
esponsable de devolver un HttpResponseobjeto. (Hay excepciones, pero las abordaremos más adelante).

Entonces, en resumen, esta función de vista devuelve una página HTML que incluye la fecha y hora actuales.
Para mostrar esta vista en una URL particular, necesitarás crear una URLconf ; consulte el despachador de URL
para obtener instrucciones.
-------------------------------
AHORA la clase 37 desafía a obtener lo siguiente, mediante templates html:

# 1.- Listar todos los empleados
# 2.- Listar todos los empleados que pertenecen a un área de la empresa
# 3.- Listar empleados por trabajo
# 4.- Listar los empleados por palabra clave
# 5.- Listar habilidades de un empleado

1-Listar todos los empleados: 

Mediante ListView 

en VISTA :  
class EmployeeListView(ListView):
    model= Employee
    template_name='employee.html'
    context_object_name='employee'

en TEMPLATE: 
<h1>Our Employees</h1> 

{%for empleado in employee%}
<li>{{empleado.first_name}} {{empleado.last_name}} </li>
{% endfor %}

2.- Listar empleados por trabajo:

<h2>Cargos Empleados</h2>
{%for empleado in employee%}
<li>{{empleado.departament}} </li>
{% endfor %}

mi intento :

<h2>Cargos Empleados</h2>
{%for empleado in employee%}
 {% if empleado.departament == 'Software Quality' %}
    <h3>QA - Software Quality</h3>
    <li>{{empleado.first_name}}</li>
    {% endif %}   
{% endfor %}
</body>

<h2>Cargos Empleados</h2>
{%for empleado in employee%}
  {%if empleado.departament == 'Human Resources'%}
      <p>{{empleado.departament}}</p>
   {%endif%}
{% endfor %}

------------
17 MARZO / clase 38

Por alguna razón la forma de enlistar los empleados según sus departamentos, planteada en los ciclos for anteriores
no retornaron en pantalla ningún contenido. En la Clase 38, el curso plantea una solución mediante Filtros en Listview.
Que veremos y analizaremos ,para poder implementar. 

Aún pendiente de mostrar en los templates:
# 2.- Listar todos los empleados que pertenecen a un área de la empresa
# 3.- Listar empleados por trabajo
# 4.- Listar los empleados por palabra clave
# 5.- Listar habilidades de un empleado


estos fueron mis ultimos intentos , se mostró

<h2>Cargos Empleados</h2>
{%for empleado in employee%}
   <p>{{empleado.departament}}</p>
   {%if empleado.departament == "Software Production"%}
      <h3>Empleados del departamento de Software Production<h3>
      <li>{{empleado.first_name}}</li>
   {%endif%}
{% endfor %}

sin embargo en el if, si pongo empleado.first_name == "Fulanito" 
y que al cumplirse, imrpima empleado.departament , ahí sí funciona. 
Algún error debe haber, quizá no sea string "empleado-departament", pero no tiene sentido
tmpoco tiene sentido que sea un tema de rutas, porque se puede llamar empleado.departament en un ciclo for
fuera de tenerlo como condicion en el if, además revisé bien la sintaxis, del cargo, llibre de espacios
o caracteres distintos a su valor string. Pero bueno en fin. 

--------------------------------------------------------------------------------------------------------------
MARZO 18  . CLASE 38 

MOMENTOOOOOOOOOOOOOOO, ENCONTRE COMO ENLISTAR EN UNA SOLA VISTA, TODAS LA ÁREAS, hacía falta llamar a empleado.departament.name
ya que empleado  estaba relacionado con departamento, pero departamento a la vez es otra tabla con sus campos, y ahí llamar el campo name.

<h3>Software Quality</h3>
{%for empleado in employee%}
   {%if empleado.departament.name == "Software Quality"%}
      <li>{{empleado.first_name}} {{empleado.last_name}}</li>
   {%endif%}
{% endfor %}

-----------------------------------------------------------------------------
Resuelto lo de arriba solo quedan 3 puntos de desafío : 

# 3.- Listar empleados por trabajo
# 4.- Listar los empleados por palabra clave
# 5.- Listar habilidades de un empleado

Listar empleados por trabajo, el primer intento fue recuperar el trabajo del empleado en el template mediante :
{{empleado.job}} , sin embargo, job es un campo que depende de otro campo, job_choices la cual es una tupla, enumerada: 


class Employee(models.Model):
    job_choices=(('0','Counter'),
                 ('1','Administrator'),
                 ('2','Economist'),
                 ('3','Developer'))
    first_name = models.CharField('Names', max_length=60)
    last_name = models.CharField('Lastnames', max_length=60)
    job=models.CharField('Job',max_length=1,choices=job_choices)
    departament = models.ForeignKey(Departament, on_delete=models.CASCADE)
    skill=models.ManyToManyField(Skill)
    SearchableFields=['first_name','last_name','job']


Por lo anterior {{empleado.job}} en template me entrega el índice del empleo de la lista job_choices, para obtener el valor
legible, debo utilar el metodo get de la siguiente manera : {{empleado.get_job_display}} esto me entrega el cargo del empleado
en el template y no solo su índice. (Gemini me dijo el metodo get_job_display)

La lógica para enlistar empleados mediante su cargo, sería la misma que para enlistar, segun departamento, solo que debería hacer
dentro de un ciclo for , un condicional if {{empleado.get_job_display}} == 'Developer' : {{empleado.name}}.

Otro caso similar en la consulta de stackoverflow, indican como resolver en views y en templates:
https://stackoverflow.com/questions/4320679/django-display-choice-value

--------------------------------------------------------------------------------------------------------
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!




Resuelto el punto 3 del desafío ahora solo falta mostrar en template:

# 4.- Listar los empleados por palabra clave
# 5.- Listar habilidades de un empleado

El punto 4, es más o menos ambiguo, no se vé necesario. El punto 5 se intentará resolver mañana, ignorando el párrafo que viene 
acontinuación y la clase 28. Ya que el desafío será acceder a un campo de nuestra tabla
principal de empleados, que mantiene la relación manytomany con la tabla skill.

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

- ---------------------MARZO 20-------------------------------

# 5.- Listar habilidades de un empleado

El listar las habilidades de un empleado, no figuró mayor dificultad, no fue necesario un metodo, ESPECIAL
COMO  {{empleado.get_job_display}}  fue el caso de acceder al valor de la tupla de el campo job. 
En este caso simplemente se accedió primeramente a todas las skilss, pertenecientes a un empleadoy luego se iteraron

EL modelo-vista- template se presenta a continuacion:

------MODELO---------

class Skill(models.Model):
    skill=models.CharField('Skills',max_length=30)

    class Meta:
        verbose_name='skill'
        verbose_name_plural='skills'

    def __str__(self):
        return self.skill 

class Employee(models.Model):
    job_choices=(('0','Counter'),
                 ('1','Administrator'),
                 ('2','Economist'),
                 ('3','Developer'))
    first_name = models.CharField('Names', max_length=60)
    last_name = models.CharField('Lastnames', max_length=60)
    job=models.CharField('Job',max_length=1,choices=job_choices)
    departament = models.ForeignKey(Departament, on_delete=models.CASCADE)
    skill=models.ManyToManyField(Skill)
    SearchableFields=['first_name','last_name','job']

    class Meta:
        verbose_name='Empleo'
        verbose_name_plural='Empleos' 
        ordering=('last_name',) 
        unique_together=('first_name','last_name',)

    def __str__(self):
        for n,role in self.job_choices:
            if n==self.job:
                return f'{self.first_name} {self.last_name} - {role}'

------VISTA----------
class EmployeeListView(ListView):
    model= Employee
    context_object_name='employee'
    template_name='employee.html'

---TEMPLATE----------

{%for empleado in employee%}
<h4>{{empleado.first_name}} - {{empleado.get_job_display}} : </h4>

{%for skill in empleado.skill.all%}
<li>{{skill.skill}}</li>
{% endfor %}
{% endfor %}

CON ESTE PUNTO TENEMOS YA RESUELTOS LOS 5 PUNTOS DE DESAFIO QUE PRESENTO EL CURSO EN LA CLASE 37.
SE LOGRARON RESOLVER !!! SIN VER LA SOLUCIONES DEL PROFESOR :DDDD <3 PROCEDO AHORA A VER LA CLASE 38 Y TOMAR APUNTES DE 
LO NUEVO QUE SE PRESENTE. SI PLANTEA HACER ALGO , SE INTENTA ANTES DE VERLO. 




Ahora veremos la solución mediante filtros. CLASS 38

Utilizando filter podemos mostrar los empleados de un determinado Departamento mediante filter. 
Ya que uno de los campos de la tabla employee, es una llave foranea , ForeignKey,  a la tabla o modelo Departament,
es decir tiene la relación uno es a muchos. Un departamento se puede relacionar a muchos empleados. 
Sin embargo mediante filter, solo se puede configurar enlistar los empleados de un departamento, para una vista , y se debe configurar
desde el backend, es decir, podemos ver en un template, la lista de los trabajadores filtrados, según un solo departamento. 

Este método no es práctico, uno espera, que el mediante la parte visual , el usuario pueda interactuar con la db.
y poder filtrar los distintos campos de la tabla de empleados u otras tablas en infinitos contextos. A cotninuación documentaré
el método de filtrado por vsita, desde el backend. utilizando el atributo queryset de ListView:

MODELO
La clase empleado que se ha utilizado desde el principio

 VISTA 

class EmployeeAreaListView(ListView):
    context_object_name='areaemployee'
    template_name='areaemployee.html'
    queryset=Employee.objetcs.filter(departament__name='Software Production')

TEMPLATE

<h1>Lista de empleados por departamento</h1>
<ul>
{%for e in object_list%}
<li>{{e}}</li>
</ul>

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

note : CRUD -> CREATE - READ- UPDATE- DELETE

La forma anterior es practicamente la peor forma para realizar filtros. 

Clase 39 'Parámetro por URL y filtro en ListView'

Ahroa para filtras se propone, no usar un parámetro de Listview como el  queryset=Employee.objetcs.filter(departament__name='Software Production')
Si no un metodo, que se puede sobreescribir :  def get_queryset(self):


def get_queryset(self):
    """
    Return the list of items for this view.
    The return value must be an iterable and may be an instance of
    `QuerySet` in which case `QuerySet` specific behavior will be enabled.
    """
    if self.queryset is not None:
        queryset = self.queryset
        if isinstance(queryset, QuerySet):
            queryset = queryset.all()
    elif self.model is not None:
        queryset = self.model._default_manager.all()
    else:
        raise ImproperlyConfigured(
            "%(cls)s is missing a QuerySet. Define "
            "%(cls)s.model, %(cls)s.queryset, or override "
            "%(cls)s.get_queryset()." % {"cls": self.__class__.__name__}
        )
    ordering = self.get_ordering()
    if ordering:
        if isinstance(ordering, str):
            ordering = (ordering,)
        queryset = queryset.order_by(*ordering)
    return queryset

esa es la funcion get_queryset(self) : , pero la reescribiremos, pero siempre debe retornar una lista de elementos.

def get_queryset(self):
    #el codigo qe queremos
    lista=Employee.objects.filter(
    departamento__name='Software Production'  
  )
    return lista   

entonces quedamos con lo siquienge

MODELO

el modelo de Employees

VISTA

class ListByAreaEmpleado(ListView):
    #'Lista empleados por Area'

    def get_queryset(self):
    #el codigo qe queremos
    lista=Employee.objects.filter(
    departamento__name='Software Production'  
  )
    return lista   

TEMPLATE

<h1>Lista de empleados por departamento</h1>
<ul>
{%for e in object_list%}
<li>{{e}}</li>
</ul>

Listo, funciona, enlista a los rtabajadores de un area especifica, utilizando un metodo sobreescrito perteneciente
a la clase que creamos que hereda los metodos y atributos de la clase ListView , ahora, el usuario no tiene acceso
a nuestras views, para poder cambiar el filtro, por esto debemos cambiar el codigo a una forma en que el filtro
pueda ser determinado desde el frontend. quedaomoos en la clase39
 

 Lo vamos a dejar hasta aqui , para mañana estar despierto en el AWS restart. 

https://ccbv.co.uk/projects/Django/5.0/django.views.generic.list/ListView/
https://ccbv.co.uk/
https://docs.djangoproject.com/es/4.2/ref/class-based-views/