Я много читал о хороших вещах в Apache Wicket, но трудно найти плохие вещи. Поскольку никакая структура всегда не является правильным решением для каждой проблемы, каковы недостатки Wicket и в каких типах проектов вы бы не использовали ее?
Возможно, это не популярный вопрос, но важный, я думаю.
Wicket требует некоторых довольно твердых методов кодирования. Например, если вы сохраняете IModel в своем компоненте, но не используете его в качестве модели компонента, он не будет автоматически отсоединен и может взорвать ваш размер сеанса. Этот вид управления не является тем, к чему привыкли большинство пользователей Java.
Калитка активна и часто обновляется. Это хорошо, но каждый раз, когда я обновляюсь до новой версии, я понимаю, что мне нужно сделать много рефакторинга, чтобы перейти к лучшим методам кодирования (1.4 введенные generics, 1.4.x, представленный onConfigure(), 1.5 имеет несколько разных стратегий ресурсов). Опять же, все хорошие обновления и подталкивают вас к лучшему коду, но я завидую людям, которые приезжают в Wicket NOW вместо двух лет назад:)
Объединив оба выше, я чувствую, что Wicket принимает некоторые реальные навыки программирования, как только вы пройдете базовый набор функций. Если вы хороший разработчик, вам понравится то, что Wicket может сделать для вас (и код довольно хорошо документирован в JavaDoc). Если вы новичок, вы можете расстроиться по мере углубления.
Кроме того, пока он "работает" в Google App Engine, я обнаружил несколько проблем, которые мешали ему комфортно работать в этой среде. Это для другого обсуждения.
Мой отказ от ответственности состоит в том, что я не использовал ничего другого, поэтому, возможно, другие структуры хуже.
В реальном мире скорость разработки очень медленная с Wicket. Если у вас нет готового компонента, который будет использоваться как рабочий стол factory на конвейере, а производительность перестанет работать до тех пор, пока вы не сможете создать новую панель. Сложность кода возрастает, и трудно прочитать код, потому что вы эффективно удваиваете строки кода, который вы должны писать. Вы постоянно смотрите, как делать тривиальные вещи в Интернете и в книгах. Например, простая кнопка reset - это одна строка HTML, но в Wicket для этого требуется Google. Это делает простые вещи трудными и трудными.
Мне еще предстоит увидеть действительно сложный интерфейс, построенный с помощью Wicket. С Wicket возможны только простые пользовательские интерфейсы, состоящие из предварительно консервированных компонентов. Каждый пользовательский интерфейс, который я видел, построенный с помощью Wicket, мог иметь более чистую базу кода, если бы это не было сделано в Wicket, и это улучшилось бы, сбросив Wicket. Wicket покупает вам ничего, как хорошие виджеты пользовательского интерфейса. Даже реализация jQuery UI Wicket уступает непосредственно использованию пользовательского интерфейса jQuery.
После прочтения десятков тысяч строк кода Wicket на моей работе я могу сказать, что код Wicket - это в основном код спагетти. Если вам нравится ulgy, неэлегантный, подробный код с дженериками и анонимными внутренними классами по всему месту, чем Wicket, это ваша вещь. Количество линейного шума очень велико. Из-за этого база кода становится менее ремонтопригодной. Это особенно актуально, если вы используете испорченную реализацию Wicket AJAX.
Несколько ответов объявляют, что калитка неспособна динамически создавать дерево компонентов. Серьезно, я думаю, вы, ребята, работаете с другой калитки там;)
Прежде всего: Wicket основан на компонентах, а не на случайном генераторе HTML.
На самом деле довольно легко получить динамическое дерево компонентов:
Хотите заменить компонент другим? Используйте Component.replaceWith(Component) (Довольно полезно в сочетании с пустым MarkupContainer)
Нужен динамически меняющийся список панелей? Поместите их в ретранслятор.
Измените компонент? Используйте Componente.setVisible()
И еще несколько способов сделать это.
Итак, те, кто думает, что вы не можете делать динамические деревья компонентов, предоставьте несколько примеров, и я с удовольствием обсужу их.
(Если вам действительно нужно быть более гибким, вы можете сделать разметку Wicket из разных источников. Что-то, что я НИКОГДА не делал для создания динамических деревьев, но чтобы иметь возможность извлекать разметку из базы данных или через сеть)
Я считаю, что калитка действительно полезна, но это были бы недостатки, которые я нашел до сих пор:
Смотрите мой ответ здесь:
Конечно, я перечислил их как преимущества, но легко понять, почему кто-то будет чувствовать обратное.
Хотя в Wicket вы ничего не можете сделать абсолютно, есть определенные базовые понятия (я бы не назвал это философией, потому что я ненавижу чрезмерное употребление этого слова), за которым вы должны следовать. Чем дальше вы отклоняетесь от этой концепции, тем труднее это превратить в Wicket.
Есть две вещи, которые я нашел раздражающими с Wicket:
Ajax-вызовы выполняются синхронно (они поставлены в очередь на стороне клиента, чтобы избежать проблем concurrency), поэтому Ajax - это только JAX. EDIT: по-видимому, я ошибся в этом, см. Комментарий к marting-g ниже.
API, похоже, не особо заботится об инкапсуляции, поэтому вы найдете множество общедоступных методов, описанных как "Это не является частью общедоступного API. Не вызывайте этот метод". (или что-то подобное).
Я не использовал Wicket, поэтому идите вперед и вниз, если хотите, но Wicket основан на компонентах. Если вы предпочитаете решение на основе компонентов, то это не будет для вас недостатком, но я обнаружил, что структура конкурирующих компонентов основана на ограничениях.
Придя из пары лет JSF (также модель на основе компонентов) в Spring MVC (больше действий) Я чувствовал, что оковы были сняты. Третий пункт в ответе mgv: "Вы не можете динамически определять деревья компонентов, поскольку вы должны определить их как в макете HTML, так и в коде Java" суммирует большую часть причины моего разочарования.
Моя основная проблема с Apache Wicket заключается в отсутствии хороших онлайн-справочных материалов. Я сделал обширные поиски Google для примеров простых вещей, таких как флажки выбора, и мне очень трудно найти что-то, что помогло бы мне не только получить окно выбора, но и понять, почему я так делаю. Кроме того, там я много искал и не нашел хорошего базового обзора ключевых концепций построения приложения Wicket.
В этот день и возраст мне не нужно покупать книгу, чтобы изучить структуру веб-программирования. На каждый другой вопрос, связанный с веб-программированием, который мне когда-либо был, ответил несколько поисковых запросов Google. Напротив, все еще есть некоторые части Wicket, которые я не понимаю, потому что я не нашел достойной документации, и задавать вопросы на форумах ограничен, потому что у меня нет того, что я чувствую, это твердое понимание Wicket после прочтения только онлайн документация.