Общий опыт разработчика, сообщество и документация
«Это просто работает»
Большая часть того, что предлагает ZK, работает очень хорошо, и функциональность обычно очень интуитивно понятна, если вы ранее разрабатывали какие-либо настольные Java-приложения. В 2007 году я провел сравнение технологий RIA, в том числе Echo2, ZK, GWT, OpenLaszlo и Flex. Echo2 и OpenLaszlo чувствовали себя неполными и глючными и, похоже, нигде не имели надлежащих артефактов Maven. GWT казался скорее техническим экспериментом, чем хорошей платформой для построения. Flex был отброшен, потому что некоторые важные артефакты Maven отсутствовали, а Flash был нереалистичным требованием для приложения. С другой стороны, ZK показался мне наиболее «естественным», и я смог быстро с ним работать. Во время моего 4-летнего путешествия с ZK я получил много тех «вау» моментов, когда я узнал все больше и больше о ZK и улучшил свое архитектурное понимание фреймворка.
В настоящее время я достаточно хорошо понимаю, что в ZK работает, что нет, а что есть проблемы, а что нет. Но, тем не менее, после получения всего этого хорошего и плохого понимания, я считаю ZK очень впечатляющим продуктом из коробки. Недостатком этого является, конечно, тот факт, что фреймворк скрывает много вещей от новичков, чтобы быть простым в использовании, и некоторые из этих вещей будут вам кусать позже , особенно если в вашем приложении много пользователей.
Это очень, очень, очень гибкий
ZK очень гибок и имеет множество интеграций. Вы хотите использовать декларативную разметку для построения деревьев компонентов? Используйте файлы ZUL. Вы хотите придерживаться простой Java? Используйте ричлеты. Вы также можете интегрировать JSP, JSF, Spring и использовать множество языков в zscript. Базовая структура также довольно гибкая, и вы можете переопределить множество вещей, если столкнетесь с проблемами.
Недостатком является то, что есть очень много способов сделать что-то правильно, и еще больше способов испортить. Гибкость сама по себе не является отрицательным моментом, но я думаю, что документация ZK не направляет пользователей в достаточной степени к лучшим практикам ZK. Каковы лучшие практики в любом случае? Во многих руководствах используется zscript, но в документах также рекомендуется избегать его из-за соображений производительности.
Форум достаточно активный
Я думаю, что форум ZK — одно из лучших мест, где можно узнать о ZK. Это довольно активно, и темы варьируются от начального уровня до глубоких технических вещей. Я сам читаю форумы почти каждый день и иногда помогаю людям с их проблемами. Меня беспокоит одна вещь: английский на форумах обычно не очень хороший, и люди часто задают слишком широкие вопросы. Я знаю, что было бы несправедливо критиковать произведения не носителей английского языка, особенно когда я сам не являюсь носителем языка. Несмотря на это, я думаю, что такой барьер существует. Например, возьмите 5 случайных тем с форума ZK и Spring Web forum.
Потоки на форумах Spring обычно более подробные и сфокусированные, а не « я новичок, и мне нужно создать приложение x с множеством функций, расскажите, пожалуйста, как все » — темы, которые вы видите на форумах ZK и люди явно тратят время на формулирование хороших и подробных вопросов. Вы увидите, что вам нужно потратить немного больше времени на форуме ZK, чтобы понять темы. Это не чья-то вина или что-либо, ни плохая вещь, это просто наблюдение. К сожалению, для меня это означает, что часть моего ограниченного времени, которое я имею для сообщества ZK, тратится только на то, чтобы понять, что говорят люди. Обычно я отвечаю на тему только тогда, когда знаю ответ сразу, или если тема касается какой-то глубокой технической вещи.
Там много документации
В прошлом документация ZK была разбросана, устарела, и некоторые из наиболее важных вещей были полностью пропущены. За последние годы документы значительно улучшились, и теперь есть отдельные подробные ссылки для конфигурации ZK , ZK на стороне клиента и стиля . Я думаю, что документация сегодня очень хорошая, и на большинство основных вопросов можно легко ответить, прочитав документы.
Как я уже упоминал выше, у ZK есть тенденция «просто работать». Общее техническое качество впечатляет и находится на одном уровне с большинством веб-фреймворков Java, но я считаю, что некоторые части ZK менее впечатляющи.
Застрял на Java 1.4
ZK построен на Java 1.4, что значительно ограничивает гибкость их API и качество внутреннего кода
Негативное влияние на внутренний код ZK
- ThreadLocals не удаляется с помощью remove () (вызов set (null) предотвращает утечку содержимого объекта, но не удаляет ThreadLocal должным образом)!
- Множество пользовательских кодов синхронизации, в которых будут работать простые структуры данных или объекты java.util.concurrent (ConcurrentHashMap, Semaphore, Atomic * и т. Д.)
- StringBuffer используется там, где уместно StringBuilder
Нет аннотаций
Лично я не фанат фреймворков, насыщенных аннотациями, потому что аннотации являются экстремально-инквизитивной функцией, и обычно вы заканчиваете аннотации строковыми значениями, которые не имеют безопасности типов. Тем не менее, я знаю, что некоторые люди были бы рады иметь API на их основе.
Нет перечислений
В ZK API есть много мест, где правильные перечисления будут намного лучше, чем хаки, которые используются в данный момент. Худшим нарушителем является Messagebox. Просто посмотрите на эту подпись:
|
1
2
3
4
5
|
public static int show(String message, String title, int buttons, java.lang.String icon, int focus) |
Тьфу … магические целые числа напоминают мне о SWT (это отличная библиотека с ужасным API). Давайте представим альтернативную версию с перечислениями и обобщениями:
|
1
2
3
4
5
|
public static Messagebox.Button show(String message, String title, Set<Messagebox.Button> buttons, Messagebox.Icon icon, Messagebox.Button focus) |
Гораздо лучше и безопаснее. Нет больше побитовой ИЛИ магии. Я мог бы закодировать это за 10 минут в ZK, если бы он использовал Java 1.5.
Нет дженериков
Это худшая часть зависания на Java 1.4.
Я просто перечислю некоторые места, где я хотел бы увидеть дженерики:
Значения коллекции в сигнатурах API
Пример в org.zkoss.zk.ui.util.Initiator:
|
1
|
void doInit(Page page, Map args); |
против
|
1
|
void doInit(Page page, Map<String, Object> args); |
Пример в org.zkoss.zk.ui.Component:
|
1
|
List getChildren(); |
против
|
1
|
List<Component> getChildren(); |
Коллекционные классы
Пример в ListModel:
|
1
2
3
4
5
|
public interface ListModel { ... Object getElementAt(int index); ...} |
против
|
1
2
3
4
5
|
public interface ListModel<T> { ... T getElementAt(int index); ...} |
Все классы ListModel * также должны быть универсальными (большинство расширений java.util.Collection).
org.zkoss.zk.ui.event.EventListener
|
1
2
3
|
public interface EventListener { public void onEvent(Event event);} |
против
|
1
2
3
|
public interface EventListener<T extends Event> { public void onEvent(T event);} |
org.zkoss.zk.ui.util.GenericAutowireComposer
|
1
2
3
4
|
public class GenericAutowireComposer { protected Component self; ...} |
против
|
1
2
3
4
|
public class GenericAutowireComposer<T extends Component> { protected T self; ...} |
Все * Рендерер классы
Пример в org.zkoss.zul.RowRenderer:
|
1
2
3
|
public interface RowRenderer { void render(Row row, Object data);} |
против
|
1
2
3
|
public interface RowRenderer<T> { void render(Row row, T data);} |
Не впечатляющие реализации push сервера
PollingServerPush по умолчанию имеет задержку и абсолютно уничтожит ваш сервер приложений, если будет много активных пользователей. CometServerPush лучше, но он не использует неблокирующий ввод-вывод и блокирует потоки сервлетов в вашем контейнере сервлетов. Давайте рассмотрим это в перспективе:
Конфигурация Tomcat 7.0 по умолчанию устанавливает максимальное количество потоков в соединителе на 200. Это означает, что если у вас есть 200 рабочих столов с кометами, Tomcat перестанет отвечать на другие запросы, поскольку все потоки используются кометой. Если в реализации вместо этого используется Servlet 3.0 или специфичные для контейнера асинхронные API, вы можете запустить Tomcat даже с одним потоком. Это, конечно, будет медленно, но не перестанет работать!
Кроме того, CometServerPush требует ZK EE, поэтому обычные пользователи зацикливаются на PollingServerPush. Я бы сказал, что это довольно большое ограничение, учитывая то, как продвигается сервер. Однако это не удивительно: правильную неблокирующую комету сложно реализовать и она требует неблокирующих компонентов во всех частях пути от браузера до кода сервлета.
ZScript
Я не люблю zscript. Возможно, это была хорошая функция много лет назад, но я считаю, что сегодня ее вообще не следует использовать. Почему, о, кому-то захочется заменить скомпилированный типобезопасный код Java на zscript без проверки типов, смешанный с шаблонами ZUL?
- «Я могу использовать Python / Ruby /…». Для некоторых это может быть правильным, но в итоге вы получите не поддерживаемый код, искаженный внутри шаблонов ZUL
- «Изменения видны при сохранении файла». Правда, но я бы никогда не пожертвовал так много только ради этой функции. И кроме того, вы можете получить аналогичный эффект с JRebel .
Итак, если вы поместите «Java-код» (= код BeanShell) в zscript, вы можете переосмыслить это.
Опора на отражение
Многие полезные функции основаны на рефлексии, которая ограничивает то, что компилятор может проверить для вас. Это очень типичная вещь во многих библиотеках / фреймворках Java, поэтому на самом деле это не относится к ZK. Как пользователь Scala, я вижу, как ограничения Java привели большинство фреймворков к пути отражения / аннотаций. Отражения не всегда можно избежать, но я думаю, что это плохой знак, если большинство полезных функций зависит от отражения. Вот некоторые особенности в ZK, которые используют отражение:
- Любой вид прослушивания событий, который не использует component.addEventListener. Это включает в себя любые классы, которые расширяют GenericEventListener (например, все предоставленные ZK классы Composer, кроме MultiComposer)
- Привязка данных
- EL выражения в шаблонах ZUL
Ссылка: Мысли о ZK Web Framework: Общий опыт и Мысли о ZK Web Framework: Технические материалы от нашего партнера JCG Йонаса Яванайнена в техническом блоге Jawsy Solutions
Статьи по Теме :