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.
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.
El modelo de programacion MVC
y realizan trabajos de modificacion y consulta
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.
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
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.
Enviar una notificación por el canal “model”, subtópico
Bases: object
Esta es un control sin implementar.
Esta es un control sin implementar.
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.
Crea un canal de comunicación temporal entre esta vista y un modelo.