2.3. Patrón MVC

2.3.1. mvc Package

Programar mediante mensajeo en un sistema de canales organizados como un arbol de tópicos,

Siguiendo la metodología MVC se crea una aplicación App que contiene la interface y la configuración básica para interactual con tres entornos distintos que se comunican a través de mensajes lanzados al aire por un canal que es escuchado sólo por los métodos que están suscritos al canal concreto, o a sus antecesores.

Se el módulo wx.lib.pubsub API3 para la separar las capas del diseño de cada uno de los tres actores principales: Modelo, Vista, y Control. Este último es el que contiene la lógica necesaria para manejar los anteriores. El Control sabe del Modelo y la Vista y puede actuar sobre ellos:

• Para solicitar que la Vista cambie o cree un panel
• Para ordenar un cambio de estade del Modelo a treavés de un comando

que utilize los Proxies del Modelo.

Las notificaciones pueden clasificarse en los siguientes casos:

• Mensajes que la Vista emite cuando se produce un evento, para que el

Control decida cómo manejarlo. - Mensajes que la Vista emite cuando requiere una actualización del estado del Modelo. - Mensajes que el Modelo emite para informar de cámbios en su estado.

• Mensajes y que el Controlador manda a la Vista,

El modelo de programacion MVC

Funciones de cada actor pricipal:

• Modelo: ofrece un conjunto Proxies(ModelInterface) que son independientes

y realizan trabajos de modificacion y consulta

• Vista sólo se decida a crear un GUI y emitir notificaciones al Control

para que decida qúe hacer. Recibe notificaciones del Control para actualizar.

-Controlador decide qúe se hace cuando la vista notifica un evento, llamando al modelo y actualizando la Vista.

Control se dedica a dirigir tanto la Vista como el Modelo.

• acepta solicitudes como “init” y “exit”
• puede denegar el acceso a una solicitud.
• decide el estado de la vista

Arbol de tópicos:

Se usa pubsub3 para crear un arbol de topicos, cada uno con sus subtípicos:

• “model”

  • query para solicitar una respuesta
  • cmd para ordenar la ejecución de un procedimiento.
  • register para añadir un nuevo procedimiento
  • log para avisar de actualizaciones de los datos del modelo.

• “view”

  • solicitar la ejecución de un procedimiento a Control, que busca en sus

  tablas que opciones tiene para llevar a cabo la misión - update para - create.menu para que modelo se registre en la vista principal

• “control” para recibir órdenes como mostrar o cerrar un panel.

  • do para
  • ask para preguntar

• “errors” Mensajes de error del

  • model, view, control, app

• “warning”: Mensajes sin importancia :)

Libreria nabla.mvc docstring

class Model

Bases: object

El Modelo debe estar separado de la Vista y el Controlador y no sabe cómo funcionan. El Control averiguae qué puede hacer un Modelo y le llama cuando lo necesita. El Modelo se dedica a ofrecer comandos que pueden ser llamados y notificarán su estado cuendo acaben de procesar la tarea, que puede haber tardado un tiempo

Cada Modelo (cada clase derivada de Model) tiene un identificador para que Control lo clasifique en su mapa de modelos. Si es una cadena vacía, se toma el nombre de la clase.

El Modelo emite notificaciones para que Vista y Controlador sepan en que estado está. Enviar notificaciones, pero no las recibe. Control es el que pasa los argumentos requeridos al Modelo para que actúe. Los procedimientos que estén disponibles pueden ser lanzados internamente pero no remotamenta mediante solicitudes, para eso está Control que tiene referencia directa a los métodos del modelo.

El Modelo puede tener que realizar una tarea que tarde segundos durante los cuales la Vista ha tenido que seguir respondiendo, lo que obliga a lanzar hilos parelelos de ejecución, que publican sus resultados para que el Control actualize la Vista.

Notify(msg=None)

Enviar una notificación por el canal “model”, subtópico

model = ''

class Strategy(view=None)

Bases: object

get_call()

Esta es un control sin implementar.

init()

nothing()

set_call()

Esta es un control sin implementar.

views = {}

class View

Bases: object

La Vista se crea al arrancar el Frame y provoca eventos para controlar sus funciones básicas y manda mensajes al Control para pedir que se ejecute algo en el Modelo. La Vista encapsula la funcionalidad básica pero delega la estrategia en el Control que define su comprotamiento.

La Vista con wxpython consiste en un conjunto de GUI que se registran en ella, una de los cuales es el principal. Estos paneles pueden tanto recibir mensajes de actualización como emitir solicitudes de comandos a Control.

Los paneles de la vista generan eventos que son respondidos sus propios métodos que también pueden emitir una solicitud a Control, abrir nuevos paneles o cerrarlos.

• Contiene una ventana principal que siempre está abierta, hasta que se cierre.
• Incluida en el conjunto de paneles que pueden estar abiertos o cerrados.
• Cada panel puede suscribirse a un canal de notificaciones o varios.
• También se suscriben a canales

Event(key)

Link(model=None)

Crea un canal de comunicación temporal entre esta vista y un modelo.

Notify(msg=None, sub='')

Request(msg=None, sub='', query=None)

call(call)

control = <nabla.mvc.Strategy object at 0x09AED310>

model = ''

wxEventNotify(event=None)