Кто нибудь работал или изучал или просто ознакамливался с проектом ZK (http://www.zkoss.org/)?
Сам я в вебе не силен, поэтому сложно делать какие либо выводы.
Но конечно понравилось то, что для разработки интерсфейса не обязательно что-то программировать на HTML или JavaScript.

Это кстати первый фреймворк, где я встретил выпадающий список с фильтром и отображением нескольких полей.

Здравствуйте, Дмитрий В, Вы писали:

ДВ>Это кстати первый фреймворк, где я встретил выпадающий список с фильтром и отображением нескольких полей.
это что-то модное? или полезное?

Здравствуйте, Lucker, Вы писали:

L>Здравствуйте, Дмитрий В, Вы писали:

ДВ>>Это кстати первый фреймворк, где я встретил выпадающий список с фильтром и отображением нескольких полей.
L>это что-то модное? или полезное?
Если Вы считаете, что это в вашем случае это не полезно, я Вас переубеждать не буду — Вам лучше знать.
Но в корпоративных проектах считается хорошим тоном пользователю при выборе значения из списка давать возможность увидеть несколько полей (например, код/наименование), а также возможность фильтровать по ним.

Здравствуйте, Дмитрий В, Вы писали:

ДВ>Кто нибудь работал или изучал или просто ознакамливался с проектом ZK (http://www.zkoss.org/)?
ДВ>Сам я в вебе не силен, поэтому сложно делать какие либо выводы.
ДВ>Но конечно понравилось то, что для разработки интерсфейса не обязательно что-то программировать на HTML или JavaScript.

глянул на проект пока не разбирался. Сразу возник вопрос:
возможно ли так:

jsp->zul->zkoss.preprocessor?

Здравствуйте, Дмитрий В, Вы писали:

ДВ>Кто нибудь работал или изучал или просто ознакамливался с проектом ZK (http://www.zkoss.org/)?

Изучаю помаленьку. У него еще и визуальный дизайнер есть (надо качать отдельно). Мне он интересен тем что можно писать на Java. Ну и весьма просто там все показалось.

Здравствуйте, Palmovod, Вы писали:

P>Здравствуйте, Дмитрий В, Вы писали:

ДВ>>Кто нибудь работал или изучал или просто ознакамливался с проектом ZK (http://www.zkoss.org/)?

P>Изучаю помаленьку. У него еще и визуальный дизайнер есть (надо качать отдельно). Мне он интересен тем что можно писать на Java. Ну и весьма просто там все показалось.
Мне кажется, главное его достояние, это то, что он основан на XUL, а HTML в нем есть постольку поскольку. XUL придумали другие люди с претензией на стандартизацию, так что компонентов в ZK много и они получились довольно продуманными. И еще прикольно то, что там сплошной ajax. Тот же JSF писался без расчета на ajax, а в архитектуре ZK сразу была заложена идея RIA.
Удивила хорошая документация (не надо искать разные книжки из серии "in action"), а еще интеграция с различными фреймворками типа Spring, Hibernate, Acegi.

Сразу видно, что разработчикам был интересен этот проект, и они не поленились сделать качественную работу.
Конечно меня не все устраивает — я не знаю, получится ли с помощью несложных манипуляций у ListBox сверху приделать фильтры над каждой колонкой (у Grid это не проблема), да и многие javascript framework'и предлагают более продвинутые компоненты, но ни у одного из них нет такой интеграции с серверной частью.

Здравствуйте, Дмитрий В, Вы писали:

ДВ>Конечно меня не все устраивает — я не знаю, получится ли с помощью несложных манипуляций у ListBox сверху приделать фильтры над каждой колонкой (у Grid это не проблема),
Оказалось, это делается элементарно.
Компоненты в зуле ( в том числе и ячейки таблицы) оказывается поддерживают неограниченный уровень вложенности.

А если мы создаем компонент, то он может описывать с помощью тегов, описывающих другие высокоуровневые компоненты:

<window title="${arg.title}" border="normal" width="360px" closable="true"
use="org.zkoss.zul.impl.FileuploadDlg">
    <label value="${arg.message}"/>
    <variables frhgh="${arg.max*16+30}" if="${arg.max > 3}"/>
    <variables frhgh="${frhgh}pt" if="${!empty frhgh}"/>
    <iframe width="100%" height="${frhgh}" style="border: 1px solid #aaa"
    src="~./zul/html/fileupload.dsp?dtid=${self.desktop.id}&amp;uuid=${self.parent.uuid}&amp;action=${arg.action}&amp;max=${arg.max}"/>
        <!-- since arg.action might contain ;jsessionid=xx, so put it to the last one -->
</window>

либо на HTML с помощью JSP/JSTL-подобного языка, который в отличие от JSP не компилируется, а интерпритируется:

<%@ taglib uri="/WEB-INF/tld/web/core.dsp.tld" prefix="c" %>
<%@ taglib uri="/WEB-INF/tld/zk/core.dsp.tld" prefix="z" %>
<c:set var="self" value="${requestScope.arg.self}"/>
<td id="${self.uuid}"${self.outerAttrs}${self.innerAttrs}>${self.columnHtmlPrefix}${self.imgTag}
<c:out value="${self.label}" maxlength="${self.maxlength}"/>
<c:forEach var="child" items="${self.children}">
    ${z:redraw(child, null)}
</c:forEach>${self.columnHtmlPostfix}</td>

Каждому компоненту могут соответствовать разные шаблоны (они определяются атрибутом mold), но java-класс один, в котором описываем всю логику поведения

Как и в JSF поддерживаются различные scope: requestScope, sessionScope и т.п..

А еще можно писать веб-страницы вообще не используя ни HTML, ни XUL, ни какого либо xml подобного языка разметки, реализуя все с помощью языка Java. Супер!
В принципе это может сильно помочь, когда надо будет какие нибудь компоненты реализовывать, типо различных списочных форм, генерящихся автоматически по аннотациям у оборажаемого в ней класса.
Кодинга меньше, качество выше, почему до сих КОРПОРАТИВНЫЕ системы пишут на низкоуровневом стратсе? Наверное у начальнегов денег слишком много?

public class TestRichlet extends org.zkoss.zk.ui.GenericRichlet {
    public void service(Page page) {
        page.setTitle("Richlet Test");
        final Window w = new Window("Richlet Test", "normal", false);
        new Label("Hello World!").setParent(w);
        final Label l = new Label();
        l.setParent(w);
        // ...
        w.setPage(page);
    }
}

Здравствуйте, Дмитрий В, Вы писали:

Разбираюсь второй день, поделюсь первыми впечатлениями.
ДВ>Мне кажется, главное его достояние, это то, что он основан на XUL, а HTML в нем есть постольку поскольку.

Именно это мне и не понравилось. Получается смешивание скриптового кода и собственно представления. Получается назад к скриптлетам, а отлаживать это все как? Как будем юнит тесты писать? А в документации все примеры именно в таком стиле.

А вообще, мне собственно больше понравилась возможность полностью писать как на свинге без всяких JSP, XUL (хотя что-то ричлеты в чистом виде у меня пока не получилось сделать, не может подхватить мой класс, пока все делаю комбинированным способом):

<window id="main" use="MyClass"/>

Вот с использованием ричлетов все получается очень круто — именно так как я и мечтал (я пока до тонкостей не добрался, но если в ричлете не отслеживается сессия — это окажется очень плохо). Хоть поддержка нормальной архитектуры ложится полностью на меня, главное что я могу все писать на Java и соответственно использовать все ее сильные стороны.

Но вот что настораживает. По крайней мере в документации все делается с использованием zscript, в результате боюсь окажется очень много приложений, использующих zkoss и написанных в ужасном стиле. Соответственно это может обеспечить дурную славу этому фреймворку.

Здравствуйте, Дмитрий В, Вы писали:

ДВ>А еще можно писать веб-страницы вообще не используя ни HTML, ни XUL, ни какого либо xml подобного языка разметки, реализуя все с помощью языка Java. Супер!
Оно и в GWT есть, так что это-то как раз без проблем. А еще в GWT очень крутой механизм интероперабельности с JavaScript'ом — ни у кого пока такой крутости нет. Ну и еще поддержка со стороны IDEA тоже очень помогает.

Здравствуйте, elmal, Вы писали:

E>Но вот что настораживает. По крайней мере в документации все делается с использованием zscript, в результате боюсь окажется очень много приложений, использующих zkoss и написанных в ужасном стиле. Соответственно это может обеспечить дурную славу этому фреймворку.

Я в ZK разочаровался немного, потому что тяжелая шняга и вообще тормозит местами
Сейчас читаю про Wicket — компонентов в нем тоже туча.
Но конечно такого мощной интеграции ajax'a в серверную часть, как у ZK, ни у кого нет.
При разработке Wicket и ZK просто ставились разные цели. Wicket больше для фронт-офиса, на zk думаю будет легко back-офисы писать.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Дмитрий В, Вы писали:

ДВ>>А еще можно писать веб-страницы вообще не используя ни HTML, ни XUL, ни какого либо xml подобного языка разметки, реализуя все с помощью языка Java. Супер!
C>Оно и в GWT есть, так что это-то как раз без проблем. А еще в GWT очень крутой механизм интероперабельности с JavaScript'ом — ни у кого пока такой крутости нет. Ну и еще поддержка со стороны IDEA тоже очень помогает.
С компонентами как-то в GWT туговато
Или может библиотеки какие-то есть?

ДВ>Но конечно такого мощной интеграции ajax'a в серверную часть, как у ZK, ни у кого нет.
А с Seam не пробовали сравнить? Вообще, пока, комбинация JSF, facelets, ajax4jsf, richfaces и, сам, собственно, seam для меня очень мощно выглядит.
И ajax очень прозрачный, ты его вообще не замечаешь, практически. И работает довольно шустро. Правда, я, пока еще только в самом начале. Но не в пример, проблем меньше, чем как я только начал работать с чистым JSF.

Здравствуйте, Дмитрий В, Вы писали:

ДВ>Я в ZK разочаровался немного, потому что тяжелая шняга и вообще тормозит местами
ДВ>Сейчас читаю про Wicket — компонентов в нем тоже туча.
Эх ... нет в жизни счастья с этими фреймворками — их куча, и везде грабли, не заметные с первого раза. Хорошо вот на .NET — там фреймворк один (текущий, правда он меняется часто до неузнаваемости в процессе развития ), все диктуется одной фирмой, проблема выброра не стоит, за тебя уже все решили .

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, Дмитрий В, Вы писали:

ДВ>>Я в ZK разочаровался немного, потому что тяжелая шняга и вообще тормозит местами
ДВ>>Сейчас читаю про Wicket — компонентов в нем тоже туча.
E>Эх ... нет в жизни счастья с этими фреймворками — их куча, и везде грабли, не заметные с первого раза. Хорошо вот на .NET — там фреймворк один (текущий, правда он меняется часто до неузнаваемости в процессе развития ), все диктуется одной фирмой, проблема выброра не стоит, за тебя уже все решили .
Ну да. В чем то плюс, в чем то минус. Но Hibernate со спрингом туда пришли из явы
Явисты не гордые, младшим братьям помогут правильные технологии юзать

Дмитрий В wrote:
> C>Оно и в GWT есть, так что это-то как раз без проблем. А еще в GWT
> очень крутой механизм интероперабельности с JavaScript'ом — ни у кого
> пока такой крутости нет. Ну и еще поддержка со стороны IDEA тоже очень
> помогает.
> С компонентами как-то в GWT туговато. Или может библиотеки какие-то есть?
Основные компоненты вроде нормальные, кроме того, в сети уже куча разных
валяется. Ну и свои при желании без проблем делаются (мы уже написали
пачку).

Еще http://www.instantiations.com/gwtdesigner/ очень помогает — рисуешь
интерфейс как для Swing'а. Потом, разве что, дизайнеру дать стили поправить.

ДВ>Но конечно такого мощной интеграции ajax'a в серверную часть, как у ZK, ни у кого нет.

Мне почти всегда хватало вот этого: http://getahead.org/dwr

Здравствуйте, Георгий, Вы писали:

ДВ>>Но конечно такого мощной интеграции ajax'a в серверную часть, как у ZK, ни у кого нет.

Г>Мне почти всегда хватало вот этого: http://getahead.org/dwr
Как на GWT то похож!
Или GWT на DWR

Hello, !
You wrote on Sun, 10 Jun 2007 09:36:29 GMT:

ДВ>>> Но конечно такого мощной интеграции ajax'a в серверную часть,
ДВ>>> как у ZK, ни у кого нет.

Г>> Мне почти всегда хватало вот этого: http://getahead.org/dwr
ДВ> Как на GWT то похож!
ДВ> Или GWT на DWR

В чем похожесть-то?
GWT — набор графических компонентов, сделанный на основе т.н. Ajax и извращений с генерацией JavaScript'a.
DWR — всего лишь механизм, обеспечивающий вызовы серверного java-кода из броузера.