Создание элементов формы на основе типа с переопределениями

Question

С несколькими приложениями, которые я создаю, я мог бы использовать возможность генерировать динамические формы для заполнения произвольных списков переменных.Например, при запуске сценария Lua, который читает в произвольном формате файла, сценарию может потребоваться уникальная информация для декодирования этого формата (например, разделительный символ для CSV).По сути, я хочу что-то похожее на инспектор Unity .

У меня есть HashMap, который отображает Class в Handler:

private interface Handler {
    Control handle(GridPane grid, Integer row);
}

private static final HashMap<Class, Handler> FormInputs =
        new HashMap<Class, Handler>() {
    {
        // String
        put(String.class, (grid, row) -> CreateStringInput(grid, row));

        // Integer
        put(int.class, (grid, row) -> CreateIntegerInput(grid, row));
        put(Integer.class, (grid, row) -> CreateIntegerInput(grid, row));

        // Float
        put(float.class, (grid, row) -> CreateFloatInput(grid, row));

        // Directory
        put(Path.class, (grid, row) -> CreateFileInput(grid, row));
        put(File.class, (grid, row) -> CreateFileInput(grid, row));

    }
};

Когда форма создается, она использует getFields() для получения списка полей из переданного Class, а когда форма создается, она создает простой GridPane и заполняет его метками и элементами управления.

Теоретически, это должно работать нормально, но с классом Path я заметил, что этот класс не всегда соответствует его предполагаемому использованию.Path может указывать на файл или каталог, для которых требуются различные настройки для диалогового окна просмотра.Точно так же String может использоваться для любого количества вещей, и может потребоваться определенная проверка.

Какой будет наиболее дружественный подход для переопределения проверки типа и явного указания, какой ввод формы использовать?Я изучал использование декораторов, но, похоже, они предназначены для расширения существующих функций декорированного объекта, тогда как я хочу наполнить их дополнительной информацией.

edit: Для дальнейшего контекста я хотел бы иметь возможность делать такие вещи, как декоратор Unity [Range ()], в результате чего числовые классы представляются ползунком между значениями min и max.

edit 2: Для пояснения и упрощения: Form класс генерирует автоматическую форму на основе класса.Например, если передать ему следующий класс

public class TestClass {
    public boolean bool1;
    public Boolean bool2;
    public String string1;
    public String string2;
    public Integer int1;
    public int int2;
    public Path path1;
    public File file1;
}

, получится следующий вид:

Я хочу иметь возможностьукажите в классе, какие поля должны обрабатываться по-разному.В идеале я также хочу, чтобы это работало, передавая массив смешанных переменных, и я хочу иметь возможность определять собственную схему, как это можно сделать с помощью Unity и пользовательских инспекторов.

Answer 1

Лучший метод, который я придумал, включает в себя небольшую перестановку.Он работает только автоматически для пользовательских классов, но допускает некоторую настройку после инициализации.

Во-первых, напишите открытый интерфейс для реализации пользовательских классов, который позволяет им определять пользовательский список элементов управления:

public interface FormLayout {
    List<Input> getLayout();
}

Затем в конструкторе вместо инициализации списка полей проверьте, определяет ли объект свой собственный макет:

public Form (Object objRef) {
    Field[] fields = objRef.getClass().getFields();
    if(objRef instanceof Form.FormLayout) {
        inputs = ((FormLayout) objRef).getLayout();
    }
    else {
        inputs = new ArrayList<>();
        for (int i = 0; i < fields.length; i++) {
            inputs.add(new Input(fields[i].getName(), FormInputs.get(fields[i].getType())));
        }
    }
}

Теперь у вас есть список определенных входных данных, которыми можно манипулировать перед построениемформа и возможность определить пользовательский макет для класса.

Дальнейшая работа должна быть сделана, чтобы обработать связывание ввода с полем, чтобы пользовательский ввод фактически достиг правильной переменной, ноэто, кажется, самый разумный подход.