Estandarización en código de OpenERP (Odoo)

OpenERP, utiliza ciertas normas y estandarizaciones que contribuyen a mantener un código ordenado y de esta forma, identificar de forma más sencilla variables, modelos, tablas o vistas dentro de una aplicación o esquema base en la estructura del código fuente.

Campos o fields

Algunos comentarios descritos en el manual Technical Memento de OpenERP, indica una serie de estandarizaciones, directrices que se declaran en archivos .py, que hacen referencia a un archivo donde se desarrollan las clases, métodos y declaración de tablas y campos de una tabla, así como también, declaración de campos que se asocian a una tabla específica.

Dentro de las convenciones para estos archivos tenemos:

many2one; este tipo de campo, su nombre debe culminar con _id, ejemplo: identificador_id

*2many; los campos que terminan con 2many, tales como: one2many y many2many; sus respectivos nombres deben culminar con el sufijo _ids, por ejemplo: identificador_ids

Tablas o modelos

Los nombres de las tablas o modelos en OpenERP, deben tener un nombre par, es decir, dos nombres separados por un punto, uno que hace referencia del módulo o aplicación y otro que hace referencia específica de la función que cumplirá en dicho módulo.

Por ejemplo, si deseamos crear una tabla asociada a Recursos Humanos, por defecto el módulo se llama hr y tiene diversas tablas asociadas, la tabla de empleados, donde irán guardados los datos de los empleados se llamará employee, finalmente el nombre de dicha tabla o modelo, se llamará: hr.employee

Aplicación o módulo

Cada aplicación o módulo lleva un nombre de referencia que será usado en gran parte del sistema, o en su totalidad, los nombres de los módulos se usan especialmente para hacer referencias en las tablas y hacer referencias en los ids de las vistas, es importante considerar un nombre relacionado con las funciones generales que tendrá intrínseco, continuando con el módulo hr de Recursos Humanos, tendrá muchas funciones asociadas con empleados, hojas de trabajo, asistencias, entre otras; cada módulo puede tener submódulos asociados por lo que se crean o desarrollan aparte del módulo principal.

Se tiene un módulo base para Recursos Humanos llamado hr pero está el módulo de hojas de trabajos o servicios que está asociado también a Recursos Humanos, diferenciado con el nombre hr_timesheet_sheet, estos nombres irán relacionados dentro del sistema, en una tabla sería de la siguiente forma:

hr.employee; donde hace referencia al módulo hr en el sistema y la tabla de employee en módulo de Recursos Humanos.

hr_timesheet_sheet.sheet; donde hace referencia al módulo hr_timesheet_sheet en el sistema y la tabla sheet dentro del módulo de Recursos Humanos.

Estas referencias también son usadas cuando se hace el llamado de la tabla en una vista, si existe una vista del módulo de Recursos Humanos en donde necesitamos mostrar un campo de dichas tablas, se haría la referencia parecida a la siguiente:

<?xml version="1.0" encoding="utf-8"?>
<openerp>
    <data>
        <record id="vista_lista_1" model="ir.ui.view">
            <field name="name">vista.lista.1</field>
            <field name="model">hr.employee</field>  <!-- Aquí está nombre de tabla -->
            <field name="arch" type="xml">
                <form version="7.0">
                    <field name="parent_id"/>
                </form>
            </field>
        </record>

        <!-- Haciendo herencia de vista en módulo hr -->
        <record id="vista_lista_1_inherit_1" model="ir.ui.view">
            <field name="name">vista.lista.1.inherit.1</field>
            <field name="model">hr.employee</field>
            <field name="inherit_id" ref="hr.vista_lista_1"/> 
            <field name="arch" type="xml">
                <form version="7.0">
                    <field name="state"/>
                </form>
            </field>
        </record>
        
    </data>
</openerp>

Así tal como se consiguen los nombres de los módulos o aplicaciones dentro del código del sistema, se consigue el directorio en la estructura del directorio addons donde están ubicados lógicamente todos módulos con sus respectivos archivos de códigos.

Atributos id y name de vistas

Las vistas tienen por defecto un campo id que genera un índice único en el sistema y es referencia para cada vista creada, dentro de un mismo módulo no debe existir identificadores con un mismo nombre, y si es posible, dentro de todo el sistema, también cada vista, posee un campo name que no es más que el mismo nombre del atributo id, unas vistas usan el mismo nombre otras vistas no usan dicho nombre, la diferencia es la separación referencia, en el atributo id usa guión bajo mientras que el name usa punto. Por ejemplo:

<?xml version="1.0" encoding="utf-8"?>
<openerp>
    <data>
        <record id="vista_lista_1" model="ir.ui.view"> <!-- Atributo id -->
            <field name="name">vista.lista.1</field> <!-- Atributo name -->
            <field name="model">hr.employee</field> 
            <field name="arch" type="xml">
                <form version="7.0">
                    <field name="parent_id"/>
                </form>
            </field>
        </record>
    </data>
</openerp>

En el caso de las vistas heredadas pude llevar le mismo patrón pero con un sufijo inherit con un correlativo, por ejemplo:

<?xml version="1.0" encoding="utf-8"?>
<openerp>
	<data>
		<record id="vista_lista_1_inherit_1" model="ir.ui.view"> <!-- Atributo id -->
			<field name="name">vista.lista.1.inherit.1</field> <!-- Atributo name -->
			<field name="model">hr.employee</field> 
			<field name="arch" type="xml">
				<form version="7.0">
					<field name="parent_id"/>
				</form>
			</field>
		</record>
	</data>
</openerp>

Las vistas que pudieran llevar o no esta convención, son las vista de acciones, las acciones muestran el atributo name, por ejemplo:

<?xml version="1.0" encoding="utf-8"?>
<openerp>
	<data>
		<record id="accion_lista_1_inherit_1" model="ir.actions.act_window">
			<field name="name">Nombre de la acción</field>
			<field name="type">ir.actions.act_window</field>
			<field name="res_model">tabla.modulo</field>
			<field name="view_type">tree</field>
			<field name="view_mode">tree</field>
		</record>
	</data>
</openerp>

Existen muchas otras convenciones que ayudan a organizar un código muy extenso.

Advertisements

About felixurbina

Humano con todos los defectos y virtudes que vienen de fábrica.
This entry was posted in Odoo, OpenERP. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s