Web2py: núcleo

Opciones de línea de comando

Hemos aprendido cómo iniciar el servidor web2py usando el widget GUI en el capítulo anterior.

Este widget se puede omitir iniciando el servidor desde command line rápido.

python web2py.py -a 'su contraseña' -i 127.0.0.1 -p 8000

Siempre que se inicia el servidor web2py, crea un archivo "parameters_8000.py"donde todas las contraseñas se almacenan en formato hash.

Para fines de seguridad adicional, se puede utilizar la siguiente línea de comando:

python web2py.py -a '<recycle>' -i 127.0.0.1 -p 8000

Para el escenario anterior, web2py reutiliza las contraseñas hash almacenadas en "parameters_8000.py".

En caso de que el archivo "parameters_8000.py"se elimina accidentalmente o por otras razones, la interfaz administrativa basada en web está deshabilitada en web2py.

Asignación / envío de URL

El funcionamiento de web2py se basa en model-view-controller, que mapea la URL en una forma específica: http://127.0.0.1:8000/a/d/f.html

Se enruta hasta la función “f()” mencionado en el controlador d.pyestá bajo la aplicación denominada "a". Si el controlador no está presente en la aplicación, web2py usa un controlador predeterminado llamado“default.py”.

Si la función, como se indica en la URL no está presente, entonces la función predeterminada llamada init()se utiliza. El funcionamiento de la URL se muestra esquemáticamente en la siguiente imagen.

La extensión .htmles opcional para la URL. La extensión determina la extensión deViewque genera la salida de la función definida en el controlador. El mismo contenido se sirve en varios formatos, a saber, html, xml, json, rss, etc.

La solicitud se pasa, en función de las funciones, que aceptan los argumentos y dan la salida adecuada al usuario. Es el controlador, que interactúa con el modelo y la vista de la aplicación para dar la salida según las necesidades del usuario.

web2py - Flujo de trabajo

El flujo de trabajo de web2py se analiza a continuación:

  • El servidor web gestiona todas y cada una de las solicitudes HTTP simultáneamente en su propio hilo.

  • El encabezado de la solicitud HTTP se analiza y se pasa al despachador.

  • El despachador gestiona las solicitudes de la aplicación y mapea el PATH_INFOen la URL de la llamada a la función. Cada llamada a función está representada en la URL.

  • Todas las solicitudes de archivos incluidos en la carpeta estática se administran directamente y los archivos grandes se transmiten al cliente.

  • Las solicitudes de cualquier cosa que no sea un archivo estático se asignan a una acción.

  • Si el encabezado de la solicitud contiene una cookie de sesión para la aplicación, se recupera el objeto de sesión; o bien, se crea una identificación de sesión.

  • Si la acción devuelve un valor como cadena, se devuelve al cliente.

  • Si la acción devuelve un iterable, se utiliza para realizar un bucle y transmitir los datos al cliente.

Modelos condicionales

En el capítulo anterior, vimos la funcionalidad del Controllers. web2py utiliza modelos, vistas y controladores en cada una de sus aplicaciones. Por lo tanto, también es necesario comprender la funcionalidad delModel.

A diferencia de cualquier otra aplicación MVC, los modelos en web2py se tratan como condicionales. Los modelos en subcarpetas se ejecutan según el uso de su controlador. Esto se puede demostrar con el siguiente ejemplo:

Considere la URL: http://127.0.0.1:8000/a/d/f.html

En este caso, ‘a’ es el nombre de la aplicación, ‘d’ es el nombre del controlador y f()es la función asociada con el controlador. La lista de modelos que se ejecutarán es la siguiente:

applications/a/models/*.py
applications/a/models/d/*.py
applications/a/models/d/f/*.py

Bibliotecas

web2py incluye bibliotecas, que están expuestas a todas las aplicaciones como objetos. Estos objetos se definen dentro de los archivos centrales en el directorio llamado "gluon".

Muchos de los módulos, como la plantilla DAL, no tienen dependencias y pueden implementarse fuera del marco de web2py. También mantiene las pruebas unitarias, lo que se considera una buena práctica.

Aplicaciones

Las aplicaciones web2py se muestran a continuación en forma de diagrama.

los Applications desarrollados en web2py se componen de las siguientes partes:

  • Models - Representa datos y tablas de bases de datos.

  • Controllers - Describe la lógica de la aplicación y el flujo de trabajo.

  • Views - Ayuda a representar la visualización de los datos.

  • Languages - describir cómo traducir cadenas en la aplicación a varios idiomas compatibles.

  • Static files - No requiere procesamiento (por ejemplo, imágenes, hojas de estilo CSS, etc.).

  • ABOUT y README - Detalles del proyecto.

  • Errors - Almacena informes de errores generados por la aplicación.

  • Sessions - Almacena información relacionada con cada usuario en particular.

  • Databases - almacenar bases de datos SQLite e información adicional de tablas.

  • Cache - Almacenar elementos de aplicaciones en caché.

  • Modules - Los módulos son otros módulos opcionales de Python.

  • Private - Los controladores acceden a los archivos incluidos, pero no directamente el desarrollador.

  • Uploads - Los modelos acceden a los archivos, pero no directamente el desarrollador.

API

En web2py, models, controllers y views se ejecutan en un entorno donde se importan ciertos objetos para los desarrolladores.

Global Objects - solicitud, respuesta, sesión, caché.

Helpers- web2py incluye una clase auxiliar, que se puede usar para construir HTML mediante programación. Corresponde a etiquetas HTML, denominadas“HTML helpers”.

Por ejemplo, A, B, FIELDSET, FORM, etc.

Sesión

Una sesión se puede definir como un almacenamiento de información del lado del servidor, que se mantiene durante la interacción del usuario en toda la aplicación web.

La sesión en web2py es la instancia de la clase de almacenamiento.

Por ejemplo, una variable se puede almacenar en sesión como

session.myvariable = "hello"

Este valor se puede recuperar como

a = session.myvariable

El valor de la variable se puede recuperar siempre que el mismo usuario ejecute el código en la misma sesión.

Uno de los métodos importantes en web2py para la sesión es “forget” -

session.forget(response);

Indica a web2py que no guarde la sesión.

Ejecución de tareas en segundo plano

Una solicitud HTTP llega al servidor web, que maneja cada solicitud en su propio hilo, en paralelo. La tarea, que está activa, tiene lugar en primer plano mientras que las demás se mantienen en segundo plano. La gestión de las tareas en segundo plano también es una de las principales características de web2py.

Las tareas que requieren mucho tiempo se mantienen preferiblemente en segundo plano. Algunos de los mecanismos se enumeran a continuación, que administran las tareas en segundo plano:

  • CRON

  • Queues

  • Scheduler

CRON

En web2py, CRONda la capacidad de ejecutar la tarea dentro de los intervalos de tiempo especificados. Cada aplicación incluye un archivo CRON, que define sus funcionalidades.

Programador

El programador incorporado ayuda a ejecutar las tareas en segundo plano al establecer la prioridad. Proporciona un mecanismo para crear, programar y modificar las tareas.

Los eventos programados se enumeran en modelos con el nombre de archivo “scheduler.py”.

Construyendo una aplicación

Tuvimos una descripción general de la creación de modelos y controladores en web2py. Aquí, nos centraremos en la creación de la aplicación denominada“Contacts”. La aplicación necesita mantener una lista de empresas y una lista de personas que trabajan en esas empresas.

Creación de modelo

Aquí, la identificación de las tablas para el diccionario de datos es el modelo. El modelo para la aplicación de contactos se creará en el "models”Carpetas. El archivo se almacena enmodels/db_contacts.py.

# in file: models/db_custom.py
db.define_table('company', Field('name', notnull = True, unique = True), format = '%(name)s')
db.define_table(
   'contact',
   Field('name', notnull = True),
   Field('company', 'reference company'),
   Field('picture', 'upload'),
   Field('email', requires = IS_EMAIL()),
   Field('phone_number', requires = IS_MATCH('[\d\-\(\) ]+')),
   Field('address'),
   format = '%(name)s'
)

db.define_table(
   'log',
   Field('body', 'text', notnull = True),
   Field('posted_on', 'datetime'),
   Field('contact', 'reference contact')
)

Una vez que se crea el archivo anterior, se puede acceder a las tablas con la ayuda de URL http://127.0.0.1:8000/contacts/appadmin

Creación de controlador

los Controller incluirá algunas funciones para listar, editar y borrar los contactos.

# in file: controllers/default.py
def index():return locals()
def companies():companies = db(db.company).select(orderby = db.company.name)
return locals()

def contacts():company = db.company(request.args(0)) or redirect(URL('companies'))
contacts = db(db.contact.company == company.id).select(orderby = db.contact.name)
return locals()

@auth.requires_login()
def company_create():form = crud.create(db.company, next = 'companies')
return locals()

@auth.requires_login()
def company_edit():company = db.company(request.args(0)) or redirect(URL('companies'))
form = crud.update(db.company, company, next='companies')
return locals()

@auth.requires_login()
def contact_create():db.contact.company.default = request.args(0)
form = crud.create(db.contact, next = 'companies')
return locals()

@auth.requires_login()
def contact_edit():contact = db.contact(request.args(0)) or redirect(URL('companies'))
form = crud.update(db.contact, contact, next = 'companies')
return locals()

def user():return dict(form = auth())

La creación de la view junto con su salida se discutirá en el próximo capítulo.