Скрытие и отображение или переключение панелей и компонентов в зависимости от пользователя и контекста

Я разрабатываю приложение калитки (в настоящее время использую калитку 1.5), которое собирается получить функцию, подобную блогу. Пользователи могут публиковать материалы или отмечать определенные бизнес-объекты как общедоступные, а другие пользователи могут их комментировать. Только пользователь-владелец может редактировать эти бизнес-объекты или записи. Я знаю, что существует несколько фреймворков, предоставляющих функции скрытия/отображения или переключения панелей в зависимости от текущего пользователя, но есть ли что-нибудь, что можно использовать для этого не только на основе пользователя, но и на основе контекста? Я знаю, что мне придется предоставить свою бизнес-логику, но я бы предпочел пропустить весь повторяющийся шаблонный код, поэтому даже подход, основанный на АОП, может помочь, но, поскольку я никогда не работал с этим раньше, я не т знаю.

Изменить. Подробнее о сценарии:

В приложении любой (вошедший в систему) пользователь может вводить, скажем, рецепты, которые он может пометить как общедоступные (может быть прочитан кем угодно) или частные (может быть прочитан только им самим). Любой зарегистрированный пользователь может комментировать любой общедоступный рецепт (публичный или частный). Частные комментарии могут быть прочитаны только комментатором и владельцем рецепта. Редактировать рецепт может только владелец. Только комментатор может редактировать свои комментарии. Только владелец рецепта или комментатор может удалять комментарии. Итак, в основном я просто ищу идею расширить классическую модель безопасности на основе ролей контекстной ролью («владелец»), и, написав это, кажется, что единственное преимущество калитки для этого было бы, что я бы предпочел решение, основанное на фреймворке, который хорошо интегрируется с wicket (или даже такое решение, в котором интеграция уже обеспечивается wicketstuff).


person Nicktar    schedule 31.01.2012    source источник
comment
Этот вопрос кажется слишком общим. В общем, скрыть/показать панели и компоненты в Wicket несложно, поэтому за ним легко подключить любую бизнес-логику. Если мы узнаем больше о вашем сценарии, кто-нибудь сможет предложить конкретное решение.   -  person biziclop    schedule 31.01.2012
comment
@biziclop Спасибо, я немного расширил сценарий, смотрите правку выше...   -  person Nicktar    schedule 01.02.2012


Ответы (1)


Если вы ищете инфраструктуру безопасности, которая поддерживает авторизацию на основе экземпляров, вы можете взглянуть на Списки управления доступом Spring Security.

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

В любом случае, чтобы «интегрировать» любое решение, которое вы выберете, на страницы Wicket, вы можете сделать что-то столь же простое, как переопределить метод «onConfigure()» (на страницах или компонентах), чтобы проверить разрешения пользователя и установить видимые/невидимые, включенные/отключенные вещи. по мере необходимости.

@Override
public void onConfigure() {
    boolean isAuthor = getCurrentUser().equals(post.getAuthor());
    deleteButton.isVisible(isAuthor);
    editLink.isEnabled(isAuthor);
}
person tetsuo    schedule 01.02.2012