Contenido del curso

La capa modelo

Ahora que Odoo conoce nuestro nuevo módulo, comencemos agregándole un modelo simple.

Los modelos describen objetos de negocio, como una oportunidad, ordenes de clientes o socios (cliente, proveedor, etc.). Un modelo tiene una lista de atributos y también puede definir su negocio específico.

Los modelos se implementan utilizando una clase Python derivada de una clase de plantilla Odoo. Se traducen directamente a objetos de base de datos, y Odoo se encarga de esto automáticamente al instalar o actualizar el módulo. El mecanismo responsable de esto es el Modelo Relacional de Objetos (ORM).

Nuestro m√≥dulo ser√° una aplicaci√≥n muy simple para mantener las tareas pendientes. Estas tareas tendr√°n un solo campo de texto para la descripci√≥n y una casilla de verificaci√≥n para marcarlas como completas. M√°s adelante deber√≠amos a√Īadir un bot√≥n para limpiar la lista de tareas de las tareas completas.

Creando el modelo de datos

Las directrices de desarrollo de Odoo establecen que los archivos Python para los modelos deben colocarse dentro de un subdirectorio models. Para simplificar, no lo seguiremos aquí, así que vamos a crar un archivo car_car.py en el directorio principal del módulo car_diagnosti.

A√Īade el siguiente contenido:

# -*- coding: utf-8 -*-

from odoo import models, fields, api
from odoo.tools.translate import _

class CarVehicle(models.Model):
    _name = 'car.car'
    _description = "Vehiculos"

    active = fields.Boolean('Activo',default=True)
    name = fields.Char(string='Vehículo')
    color = fields.Integer(string='Color')

La primera línea es un marcador especial que indica al intérprete de Python que este archivo tiene UTF-8 para que pueda esperar y manejar caracteres no ASCII. No usaremos ninguno, pero es una buena práctica tenerlo de todos modos.

La segunda l√≠nea es una instrucci√≥n de importaci√≥n de c√≥digo Python, haciendo disponibles los objetos¬†models¬†y¬†fields¬†del n√ļcleo Odoo.

La cuarta línea declara nuestro nuevo modelo. Es una clase derivada de models.Model.

La siguiente línea establece el atributo _name que define el identificador que se utilizará en Odoo para referirse a este modelo. Toma en cuenta que el nombre real de la clase Python, CarVehicle en este caso, carece de significado para otros módulos Odoo. El valor _name es lo que se utilizará como identificador.

Observa que esta y las siguientes líneas tienen sangría. Si no estás familiarizado con Python, debes saber que esto es importante: la sangría define un bloque de código anidado, por lo que estas cuatro líneas deben tener estar todas igual sangría.

Luego, tenemos el atributo modelo _description . No es obligatorio, pero proporciona un nombre fácil de usar para los registros del modelo, que puede utilizarse para mejores mensajes de usuario.

Las tres √ļltimas l√≠neas definen los campos del modelo. Vale la pena se√Īalar que¬†name¬†y¬†active¬†son nombres de campos especiales. De forma predeterminada, Odoo usar√° el campo de¬†name¬†como el t√≠tulo del registro al referenciarlo de otros modelos. El campo¬†active¬†se utiliza para inactivar los registros y, por defecto, s√≥lo los registros activos ser√°n mostrados. Lo utilizaremos para borrar las tareas completadas sin eliminarlas de la base de datos.

En este momento, este archivo a√ļn no es utilizado por el m√≥dulo. Debemos decirle a Python que lo cargue con el m√≥dulo en el archivo¬†__init__.py. Vamos a editarlo para agregar la siguiente l√≠nea:

from . importar car_car

¡Eso es! Para que nuestros cambios de código de Python entren en vigor, la instancia de servidor debe reiniciarse (a menos que esté utilizando el modo --dev).

No veremos ninguna opci√≥n de men√ļ para acceder a este nuevo modelo ya que no los hemos a√Īadido a√ļn. Sin embargo, podemos inspeccionar el modelo reci√©n creado usando el men√ļ¬†Technical. En el men√ļ superior¬†Settings, ve a¬†Technical | Database Structure | Models, busca el modelo¬†car.car¬†la lista y haz clic en √©l para ver su definici√≥n:


Si todo va bien, se confirma que el modelo y los campos fueron creados. Si no puedes verlos aquí, intenta reiniciar el servidor con una actualización de módulo, como se describió anteriormente.

También podemos ver algunos campos adicionales que no declaramos. Estos son campos reservados que Odoo agrega automáticamente a cada modelo nuevo. Estos son los siguientes:

  • id¬†es un identificador num√©rico √ļnico para cada registro del modelo.
  • create_date¬†y¬†create_uid¬†especifican cu√°ndo se cre√≥ el registro y qui√©n lo cre√≥ respectivamente.
  • write_date¬†y¬†write_uid¬†confirman cu√°ndo el registro fue modificado por √ļltima vez y quien lo modific√≥ respectivamente.
  • __last_update¬†es un ayudante que en realidad no se almacena en la base de datos. Se utiliza para verificaciones de concurrencia.

A√Īadiendo pruebas automatizadas

Las mejores pr√°cticas de programaci√≥n incluyen tener pruebas automatizadas para tu c√≥digo. Esto es a√ļn m√°s importante para lenguajes din√°micos como Python. Como no hay ning√ļn paso de compilaci√≥n, no puede estar seguro de que no haya errores sint√°cticos hasta que el int√©rprete realmente ejecute el c√≥digo. Un buen editor puede ayudarnos a detectar estos problemas con antelaci√≥n, pero no puede ayudarnos a asegurar que el c√≥digo se ejecute como lo desean las pruebas automatizadas.

Odoo soporta dos formas de describir las pruebas: ya sea utilizando archivos de datos YAML o utilizando c√≥digo Python, basado en la biblioteca¬†Unittest2. Las pruebas YAML son un legado de versiones anteriores, y no se recomiendan. Preferiremos usar pruebas de Python y a√Īadiremos un caso b√°sico de prueba a nuestro m√≥dulo.

Los archivos de código de prueba deben tener un nombre que empiece por test_ y se debe importar desde tests / __ init__.py. Pero el directorio de test (o submódulo Python) no se debe importar desde la parte superior del módulo __init__.py, ya que se descubrirá y cargará automáticamente sólo cuando se ejecuten pruebas.

Las pruebas deben colocarse en un subdirectorio¬†test/. A√Īade un archivo¬†tests / __ init__.py¬†con lo siguiente:

from . import test_car_diagnostic

Ahora, a√Īade el c√≥digo de prueba real dispon√≠ble en el archivo¬†tests/test_car.py:

# -*- coding: utf-8 -*- 
from odoo.tests.common import TransactionCase 
 
class TestCar(TransactionCase): 
 
    def test_create(self): 
        "Create a simple Todo" 
        Car= self.env['car.car'] 
        car= Car.create({'name': 'Test Car'}) 
        self.assertEqual(car.active, True)

Esto agrega un caso simple de prueba para crear una nueva tarea y verifica que el campo ** Active** Tiene el valor predeterminado correcto.

Ahora queremos hacer nuestras pruebas. Esto se hace agregando la opción --test-enable durante la instalación del módulo:


$ ./odoo-bin -d car_diagnostic -i car_diagnostic --test-enable

El servidor Odoo buscará un subdirectorio tests/ en los módulos actualizados y los ejecutará. Si alguna de las pruebas falla, el registro del servidor te mostrará eso.

Vistas
132 N√ļmero de vistas
3 Vistas de miembros
129 Vistas p√ļblicas
Acciones
0 Gustos
0 No me gusta
0 Comentarios
Compartir en redes sociales
Compartir enlace
Usar un enlace permanente para compartir en redes sociales
Compartir por correo

Por favor iniciar sesión para compartir esto webpage por correo.