Pregunta

Estoy a punto de refactorizar una aplicación Swing de usar ActionListeners a clases Action porque me di cuenta de que muchos de mis elementos de menú se va a utilizar en una barra de herramientas también.

En este momento tengo una llamada ImportExport clase que se ocupa del estado del modelo subyacente y luego muestra los cuadros de diálogo de usuario adecuados. ImportExport tiene las funciones save(), saveAs() y open(). Cuando un usuario hace clic en el elemento de menú "Abrir", el oyente de action llama open(), open() comprueba en primer lugar si el modelo tiene cambios y si ese es el caso muestra un diálogo que pregunta al usuario si quiere guardar primero. Ahora bien, si el usuario hace clic "Sí" open() llamadas save() que a su vez realiza algunas comprobaciones y muestra diálogos de usuario. save() es bastante persistente: La única forma de salir de esta acción es o bien por el ahorro de éxito o decidir el usuario que quiere cancelar. Me tiene muy en cuenta la retroalimentación que proporciona save() y si un usuario quiere cancelar también cancelar la función de llamada open().

quería dividir la clase ImportExport en tres clases (OpenAction, SaveAction y SaveAsAction), cada uno de ellos la subclasificación AbstractAction y, finalmente, deshacerse de la clase ImportExport. Y aquí es donde surge mi problema: ¿Cómo le digo al SaveAction para ejecutar si el usuario desea guardar el modelo antes de abrir otro? Y ¿cómo puedo obtener retroalimentación si el usuario decide cancelar?

Es esto el enfoque correcto? No me gusta haber duplicado código en el salvamento y la acción abierta y ya he puesto tanta funcionalidad como sea posible en mi modelo, pero el usuario subyacentes diálogos son Obviamente, tenemos fuera de lugar por lo que esto no es una opción. Action fue diseñado en absoluto para mantener este tipo de funcionalidad o sould yo sigo mi clase ImportExport y simplemente delegar toda la acción llama a las funciones apropiadas en ImportExport. ¿Cómo se utiliza Actions?

¿Fue útil?

Solución

A veces añadir una acción de 'controlador' cuando hay un árbol de decisión en cuestión. OpenAction, acciongrabar y SaveAsAction serían subclase este controlador de Acción. La acción del controlador determinaría el estado del modelo y solicitar más información del usuario si es apropiado y luego llamar a la subclase correcta.

Otros consejos

Me gustaría crear una clase ImportExportController, teniendo estos métodos: open, save, saveAs. Este controlador sabría la lógica de negocio.

Mis clases Action no contener una gran cantidad de lógica de negocio. Sólo podrían llamar al controlador.

Sin embargo, estas acciones podrían contener todas las etiquetas, iconos, acelerador ... que deben ser mostradas en JButton, JMenuItem, etc.

Para mí, Actions son clases orientadas interfaz gráfica de usuario, que se utiliza por conveniencia (y que son muy conveniente!), Pero no hay clases dedicadas a manejar la lógica de negocio.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top