É sempre bom conversar com um aplicativo que lembre de seus hábitos e como se você sentisse o que queria. Qualquer biblioteca ou plataforma de interface do usuário possui, infelizmente, apenas funcionalidade básica e um conjunto de componentes. Por exemplo, se uma coluna em uma tabela não se move ou não pode ser classificada por ela, um aplicativo no qual ela é usada dificilmente pode ser chamado de amigável. Felizmente, hoje você não surpreenderá ninguém com essa funcionalidade. No entanto, nem todos os programas se lembram da posição desta coluna e na próxima sessão a exibirão no mesmo local. Também pode ser irritante definir a posição do separador sempre no SplitPane ou inserir os mesmos parâmetros de filtro. Como regra, essas comodidades devem ser fornecidas pelos próprios desenvolvedores.
Existem muitos exemplos de melhorias aparentemente pequenas, mas as soluções oferecidas pela plataforma são apenas duas e, em essência, são semelhantes: crie seu próprio componente com base na base, crie sua capa no componente de base, redefinindo o comportamento. Nenhum desses métodos é fácil de implementar; além disso, cada componente precisará gravar seu próprio componente do adaptador. Eu conheci algumas pessoas com quem esse método era mais familiar e compreensível.
Mas ele está longe de ser o único. E se pegarmos os recursos da plataforma que suporta o modelo de navegador para o Node filho e, ao adicionar ou remover o subgráfico Node , executamos um conjunto de plug-ins, cada um dos quais envolvido em seu próprio trabalho específico? Um é capaz de lembrar e restaurar tudo durante uma segunda sessão, o outro - os componentes especificados são alterados pelo menu de contexto, adicionando a função de copiar texto. Alguns deles adicionam três pontos no final do texto, se não couber, e quando você passa o mouse sobre o mouse, ele exibe uma dica com texto completo apenas se não couber. Mais importante ainda, não importa de qual biblioteca esse componente é, se podemos herdá-lo e redefinir o comportamento de que precisamos. Tudo o que precisamos neste caso é ensinar o plug-in a trabalhar com os componentes necessários de diferentes maneiras, se necessário.
Pode ser um ouvinte para uma coleção de filhos:
private final ListChangeListener changeListener = (ListChangeListener<Node>) (ListChangeListener.Change<? extends Node> c) -> { if (c.next()) { c.getAddedSubList().forEach(this::applySettingsForNodeAndAddListenerForItsChild); } };
Esse seria o código de processamento para cada Nó modificado:
private void applySettingsForNodeAndAddListenerForItsChild(Node n) { if (!checkApplySettings(n)) { apply(n); ObservableList<Node> children = getChildren(n); if (children != null) { addListnerForUpdateChildren(children); } markNodePropertyApplied(n); } }
E esse é o código que chama diretamente o próprio plug-in, registrado neste 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; }
Aqui está a interface do próprio plugin:
public interface SettingsPlugin { public Node apply(Node node, Map<String, Object> userSettings); }
Só é necessário registrar o ouvinte uma vez na coleção de elementos filho Root do elemento Scene e, no restante do subgráfico, ele se registrará ...
Recentemente, fiz uma analogia sobre os recursos das plataformas para aplicativos da Web e de desktop. Seria interessante saber como essa funcionalidade pode ser implementada em diferentes estruturas.