Вопрос стиля - переменные-члены и get (путь) - PullRequest
2 голосов
/ 09 декабря 2011

Всякий раз, когда мне нужно добавить какой-либо компонент (A) в AjaxRequestTarget другого компонента (B) (обычно оба потомка одного и того же родителя, я сталкиваюсь с одним и тем же решением:

Сделать A переменной-членом родительского компонента по сравнению с использованием метода get (path) родителей. Оба варианта имеют свои плюсы и минусы, и я не могу решить, что будет лучше с точки зрения «лучшего» кода ...

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

Любые намеки будут оценены.

Редактировать: Это относится к Wicket 1.4, так как Wicket 1.5 решает это с помощью EventBus

Ответы [ 2 ]

8 голосов
/ 09 декабря 2011

Вместо этого используйте механизм событий Wicket 1.5 для обновления компонентов с использованием Ajax. Таким образом, вы будете отделять издателя и подписчика. См., Например, мою презентацию о новых функциях в Wicket 1.5, представленную на JavaZone'11 (пропустите примерно до 51 минуты разговора).

Взято из заметок о выпуске Wicket 1.5:

Межкомпонентные события

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

/**
 * Objects that can send events
 */
public interface IEventSource {
    <T> void send(IEventSink sink, Broadcast broadcast, T payload);
}

и

/**
 * Objects that can receive events
 */
public interface IEventSink
{
    /**
     * Called when an event is sent to this sink
     */
    void onEvent(IEvent<?> event);
}

Классы, которые реализуют эти интерфейсы и могут, таким образом, участвовать в механизме событий: Component, RequestCycle, Session и Application.

Механизм допускает различные методы трансляции событий, определенные здесь:

/**
 * Defines the event broadcast type.
 */
public enum Broadcast {
    BREADTH,
    DEPTH,
    BUBBLE,
    EXACT;
}

В wicket-examples есть пример , который демонстрирует использование этого.

Приложения могут регистрировать пользовательские диспетчеры событий в FrameworkSettings; диспетчеры могут быть использованы для создания пользовательских механизмов доставки событий. Например, пользовательский механизм IEventDispatcher может направлять события в аннотированные методы, например:

public class MyComponent extends Component {
    @OnEvent
    private void onUserAdded(UserAddedEvent event) {...}
}

, где UserAddedEvent - объект полезной нагрузки события.

Будет вызываться метод по умолчанию Component#onEvent, даже если пользовательские диспетчеры зарегистрированы.

Событие по умолчанию вызывается всякий раз, когда Wicket начинает создавать ответ AJAX. Полезная нагрузка события - AjaxRequestTarget, используемая для события. Пример реализации:

// component that always adds itself to the ajax response
public class MyComponent extends Component {
    public void onEvent(IEvent event) {
        if (event.getPayload() instanceof AjaxRequestTarget) {
            ((AjaxRequestTarget)event.getPayload()).add(this);
         }
    }
}
1 голос
/ 10 декабря 2011

Я частично вернул перенесенные события в Wicket 1.3 для взаимодействий ajax, которые должны работать с 1.4. Он не имеет всех функций в событиях Wicket 1.5 и не так эффективен, но пока работает хорошо. Может оказаться полезным отсоединить ваши компоненты.

Как и дополнительный бонус, события работают на страницах, созданных из (1) модального окна создателя страницы (2) всплывающих окон

Слишком много исходного кода для публикации здесь, но вот ссылка на пример проекта + источник:

https://github.com/robmcguinness/wicket-events

Примеры в источнике включают события, которые передаются из: (1) страницы на панель (2) модальной страницы на открыватель страницы (3) всплывающее окно на открыватель страницы

...