Калитка: Можно ли отображать компоненты панели на основе страницы, на которую добавлена ​​панель?

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

Вот сценарий. Допустим, у меня есть панель информации о клиенте с 25 точками данных (имя, доб, адрес, телефон и т. д.). Я хочу повторно использовать эту панель на многих разных страницах сайта. Теперь предположим, что у меня есть следующие критерии на 3 разных страницах, на которых отображается панель:

  • Страница 1 — все поля видны и доступны для редактирования
  • Страница 2 — Дата рождения, пол, имя клиента видны, но недоступны для редактирования, все остальные поля видны и доступны для редактирования
  • Страница 3 - Дата рождения и пол не видны, адрес виден и редактируется, все остальные поля видны, но не редактируются.

Есть ли способ использовать ту же панель (чтобы уменьшить дублирование кода), но управлять ее компонентами на основе текущей страницы, на которую загружена панель?

Спасибо за любую помощь!


person klactose    schedule 25.06.2012    source источник


Ответы (3)


Я бы посоветовал не изменять видимость и редактируемость неявно, как это. Вместо этого рассмотрите возможность сделать его явным на основе аргументов конструктора для компонента или дополнительных методов пользовательского компонента.

person Geoff Reedy    schedule 25.06.2012
comment
Да, я надеялся на решение, которое позволило бы передать список полей, которые нужно скрыть, и список полей, которые можно сделать недоступными для редактирования. Просто не был уверен, поддерживает ли калитка такое поведение. Судя по вашим ответам и ответам Артбристола, может. - person klactose; 26.06.2012
comment
Самый простой способ — объявить перечисление в классе вашей панели с тремя значениями: FULL_EDIT, PARTIAL_EDIT, HIDDEN_EDIT (или что-то в этом роде), описывающее доступные режимы работы, и заставить вашу страницу передавать его экземпляр на панель. Помните, чем меньше страницы знают о внутренностях панели, тем лучше. - person biziclop; 26.06.2012
comment
Проблема, которую я вижу при добавлении перечисления, заключается в том, что тогда панель должна будет знать каждую уникальную конфигурацию и реализовывать сложные операторы if/then или switch, которые должны поддерживаться по мере добавления новых страниц (с новыми требованиями к конфигурации). - person klactose; 26.06.2012

Внутри вашей панели вы можете вызвать метод getPage(). Либо вы можете проверить, является ли страница экземпляром определенного класса, либо вы можете получить класс страницы, вызвав getPageClass().

Видимость ваших компонентов внутри панели можно настроить, вызвав метод setVisible() или переопределив метод isVisible(). Если компоненты должны быть редактируемыми, это можно контролировать с помощью метода isEnabled() (или переопределения setEnabled()).

class YourPanel extends Panel {
    public YourPanel() {
        add(new TextField("name") {
                @Override
                boolean isVisible() {
                    return getPage().getPageClass().equals(Page2.class);
                }
        }
        TextField genderTextField = new TextField("gender");
        genderTextField.setVisible(!getPage().getPageClass().equals(Page3.class));
        add(genderTextField);
    }
}

Как видите, для многих компонентов и многих случаев проверить код будет достаточно сложно. Возможно, вы сможете получить более чистый код, если создадите пользовательские панели, добавите компоненты в соответствии с их правилами видимости и редактируемости и будете контролировать все панели, если они видны и/или доступны для редактирования.

person magomi    schedule 25.06.2012
comment
Я пытался избежать жесткого кодирования атрибутов в панели на основе конкретных страниц. Надеялся на более гибкое решение. Я также надеялся избежать дублирования информации на нескольких разных пользовательских панелях, поскольку это действительно одна и та же информация снова и снова. - person klactose; 26.06.2012

Согласно другому ответу, вы можете вызвать setVisible() и т.п., чтобы настроить внешний вид.

Однако я не рекомендую вам связывать панель с отображаемой страницей; это приведет к циклической зависимости, и каждый раз, когда вы хотите повторно использовать панель на странице нового типа, вам придется добавлять еще одну проверку для новой страницы. Вместо этого просто сделайте панель настраиваемой (лучше всего сделать это во время строительства, передав такие параметры, как boolean addressVisible).

person artbristol    schedule 25.06.2012
comment
Точно, я пытался избежать всякой привязки панели к странице. Определенно хотел пойти по маршруту параметра. Я поиграю с этим и посмотрю, как это работает. - person klactose; 26.06.2012