Comments 13
Так а что за плагин-то?
Консоль может быть достаточно дружелюбной, если пользоваться сборщиками (Например Maven).
Кроме того создав такой проект при помощи Maven а не средствами NetBeans вы получаете простой способ управления проектом, легкую переносимость на другую IDE, но при этом ничего не теряете при работе в NetBeans.
За описание фреймворка отдельное спасибо отдельное спасибо. Мне как раз скоро пригодиться.
Кроме того создав такой проект при помощи Maven а не средствами NetBeans вы получаете простой способ управления проектом, легкую переносимость на другую IDE, но при этом ничего не теряете при работе в NetBeans.
За описание фреймворка отдельное спасибо отдельное спасибо. Мне как раз скоро пригодиться.
плагин так и называется «Wicket 1.4 Support»
Основное «веселье» с Wicket начинается при сериализации сессии. Следить, чтобы ничего лишнего к графу объектов UI не прицепилось…
А вас не напрягает что исходники идут вместе с сорцами?
Кроме того, я заметил, что приходится дважды описывать форму — в html и в java. Мне кажется это существенный минус Wicket
Кроме того, я заметил, что приходится дважды описывать форму — в html и в java. Мне кажется это существенный минус Wicket
На счет исходников меня особо не напрягает, а что касается описания форм дважды — в классическом стиле без платформы так же создается HTML форма и отдельно ее обработчик, потому существенным минусом я бы это не назвал.
Это не минус, это плюс. Хорошей практикой является разделение кода и представления. Некоторые фреймворки не поддерживают такого разделения в принудительном порядке, что приводит к созданию неудобоваримого кода, который очень сложно сопровождать.
Кроме того, Wicket в известной степени позволяет манипулировать HTML-тегами, что даёт дополнительную гибкость при разработке. К сожалению, о полной манипуляции разметкой и URL-ами в компонентно-ориентированном фреймворке речи быть не может и это было основной причиной, по которой я от казался от Wicket.
Кроме того, Wicket в известной степени позволяет манипулировать HTML-тегами, что даёт дополнительную гибкость при разработке. К сожалению, о полной манипуляции разметкой и URL-ами в компонентно-ориентированном фреймворке речи быть не может и это было основной причиной, по которой я от казался от Wicket.
Да, но разделение кода и представления имеет цель разделить логику обработки данных и их представление. А тут к логике приложения добавляется дублирование вьюшки. Это снижает гибкость и добавляет гимора, когда нужно вьюшку изменить.
А чем сейчас пользуетесь?
А чем сейчас пользуетесь?
Это особенность компонентно-ориентированного подхода. В общем случае компонента в Wicket — это класс-контроллер, файл разметки и локализационные файлы. Обязательным является лишь контроллер. При использовании компоненты в разметке она представлена тегом-placehoder-ом, а в логике — объектом определенного класса. Такой подход даёт возможность программной манипуляции со свойствами и обработчиками событий компоненты. Скажем, переназначить ID placehoder-а компоненты можно лишь программно.
Сейчас я использую Spring MVC (с аннотациями, конечно) + Freemarker. Это более низкий уровень разработки, зато и ограничений никаких.
Сейчас я использую Spring MVC (с аннотациями, конечно) + Freemarker. Это более низкий уровень разработки, зато и ограничений никаких.
На самом деле здесь не дублирование, а определение точек стыковки.
И, понятное дело, необходимо следить за соответствием имен в модели и в представлении.
К счастью, в наше время за соответствием следит IDE.
И, понятное дело, необходимо следить за соответствием имен в модели и в представлении.
К счастью, в наше время за соответствием следит IDE.
Вобще, неплохо в начале хоть в двух словах рассказать о каком Викете идёт речь. Надеюсь что в будущем процент статей с-места-в-карьер уменьшится.
Sign up to leave a comment.
Первые шаги с Netbeans и Wicket