Siempre es agradable hablar con una aplicación que recuerda tus hábitos y, como si sintieras lo que quieres. Cualquier biblioteca o plataforma de interfaz de usuario tiene, por desgracia, solo una funcionalidad básica y un conjunto de componentes. Por ejemplo, si una columna de una tabla no se mueve o no puede ser ordenada por ella, entonces tal aplicación en la que se usa difícilmente se puede llamar amigable. Afortunadamente, hoy no sorprenderá a nadie con tal funcionalidad. Sin embargo, no todos los programas recordarán la posición de esta columna y en la próxima sesión la mostrarán en el mismo lugar. También puede ser molesto establecer la posición del separador cada vez en SplitPane o ingresar los mismos parámetros de filtro. Como regla general, tales servicios deben ser proporcionados por los propios desarrolladores.
Hay muchos ejemplos de mejoras aparentemente tan pequeñas, pero las soluciones que ofrece la plataforma son solo dos, y en esencia son similares: cree su propio componente basado en la base, cree su Skin en el componente base, redefiniendo el comportamiento. Ninguno de estos métodos es fácil de implementar; además, cada componente necesitará escribir su propio componente adaptador. Conocí a algunas personas para quienes este método era más familiar y comprensible.
Pero él está lejos de ser el único. ¿Qué sucede si tomamos las capacidades de la plataforma que admite la plantilla del navegador para el nodo secundario y, al agregar o eliminar el subgrafo del nodo , ejecutamos un conjunto de complementos, cada uno de los cuales se dedica a su propio trabajo específico? Uno puede recordar y restaurar todo durante una segunda sesión, el otro: los componentes especificados se cambian mediante el menú contextual, agregando la función de copiar texto. Algunos de ellos agregan tres puntos al final del texto si no encaja, y cuando pasa el mouse por encima, muestra una pista con el texto completo, solo si no encaja. Lo más importante, no importa de qué biblioteca sea este componente, si podemos heredar de él y redefinir el comportamiento que necesitamos. Todo lo que necesitamos en este caso es enseñarle al complemento a trabajar con los componentes necesarios de diferentes maneras, si es necesario.
Esto podría ser un oyente para una colección de niños:
private final ListChangeListener changeListener = (ListChangeListener<Node>) (ListChangeListener.Change<? extends Node> c) -> { if (c.next()) { c.getAddedSubList().forEach(this::applySettingsForNodeAndAddListenerForItsChild); } };
Ese sería el código de procesamiento para cada nodo modificado:
private void applySettingsForNodeAndAddListenerForItsChild(Node n) { if (!checkApplySettings(n)) { apply(n); ObservableList<Node> children = getChildren(n); if (children != null) { addListnerForUpdateChildren(children); } markNodePropertyApplied(n); } }
Y tal es el código que llama directamente al complemento en sí, que está registrado en este tipo de componente:
public Node apply(Node node) { List<SettingsPlugin> settingsPlugins = settingsMap.get(Node.class); if (settingsPlugins != null) { for (SettingsPlugin plugin : settingsPlugins) { node = plugin.apply(node, userSettings.getSettings()); } } List<SettingsPlugin> settingList = settingsMap.get(node.getClass()); if (settingList != null) { for (SettingsPlugin plugin : settingList) { node = plugin.apply(node, userSettings.getSettings()); } } return node; }
Aquí está la interfaz del complemento en sí:
public interface SettingsPlugin { public Node apply(Node node, Map<String, Object> userSettings); }
Solo es necesario registrar al oyente una vez en la colección de elementos secundarios Root del elemento Scene , y en el resto del subgrafo, se registrará a sí mismo ...
Recientemente, hago una analogía sobre las capacidades de las plataformas para aplicaciones de escritorio y web. Sería interesante saber cómo se puede implementar dicha funcionalidad en diferentes marcos.