Котъ уже статьи написал, кажется, про всё крупное Java`вское, кроме Cocoon`а . Вот, я решил в силу необходимости в нём подразобраться и пошарил в инете. Вот, что нашлось:

Начинаем работать с Cocoon 2
Построение XML-порталов на основе Cocoon

IMHO, для затравки пока что катит. Найду ещё чего на великом и могучем - кину (и вы кидайте, если найдёте )

Се ля ви, спасибо за то, что поднял эту тему. Это одна из вещей, о которых я давно хотел поговорить. Как я понял из статьи, в Cocoon все основано на XSLT преобразованиях. Кто нибудь может мне рассказать, в чем там кайф? Ну не вижу я, как программирование в XML может быть более приятным и/или более мощным (powerful), чем программирование на языке, который специально предназначен для программирования.

Идеи, плиз?

Я писал на XSL какое-то время достаточно плотно. Там весь кайф в том, что это преобразование расчитано именно на древообразную структуру XML. Т.е. надо только назначить узел и указать правила, какой узел должен получится после. Что конечно удобно.
Писал даже верификатор XML на XSL - потратил гораздо меньше времени, чем писал бы на том же Си.

Цитата(AntonSaburov @ 14.6.2005, 19:09)

Там весь кайф в том, что это преобразование расчитано именно на древообразную структуру XML. Т.е. надо только назначить узел и указать правила, какой узел должен получится после

Хорошо, допускаю. Но как XSLT может помочь генерировать HTML? Я понимаю, что в веб страница - это тоже дерево, и ее можно описать на XML, но тогда получается, что вместо кодирования в HTML мы занимаемся кодированием в XML, да еще должны написать правила трансформации. Кстати, как они хоть выглядят?

Цитата(AntonSaburov @ 14.6.2005, 19:09)

Писал даже верификатор XML на XSL

Пожалуйста, можно поподробнее? В чем заключалась задача? Я просто пытаюсь сообразить, как бы это выглядело на Java.

Цитата(Stampede @ 14.6.2005, 20:42)

вместо кодирования в HTML мы занимаемся кодированием в XML

Есть область пересечения XML и HTML-документов, а именно, стандарт XHTML - в неё и происходит перекодирование.

А вообще, XSL-преобразования не имеют никакого отношения к Java (т.к. это - отдельный язык) и у нас есть специальный форум по XML для таких вопросов.

Цитата

А вообще, XSL-преобразования не имеют никакого отношения к Java

В контексте разговора о Cocoon - думаю, имеют. Потому что, насколько я понял из статьи, там все построено на XML и преобразованиях (и речь не только о генерации HTML). В этом фреймворке вообще хоть есть место для Java-программирования?

Если нет, то я хочу повторить вопрос, к которому по большому счету сводится применимость Cocoon: неужели программировать на XML (и XSL) легче, чем на Java? Учитывая, что функциональность веб приложения может иметь не только документо-ориентированную, но и транзакционную семантику.

Цитата(Stampede @ 15.6.2005, 00:15)

В этом фреймворке вообще хоть есть место для Java-программирования?

Конечно есть, Cocoon замечательно интегрирован с J2EE, ибо сам написан на Java.
Вот вроде неплохая статья об этом: http://www.optim.ru/cs/2003/1/Podhodi/podhodi.asp, в частности от туда:

Цитата

Типовой сценарий доступа к данным в этом случае описывается следующей схемой:     клиент запрашивает определенный документ;     сервер находит (генерирует) этот документ;     сервер находит (генерирует) соответствующее преобразование и применяет его к этому документу;     результат преобразования (требуемый документ) возвращается клиенту. Чтобы получить такой документ, Cocoon использует конвейеры, которые состоят из трех типов базовых компонентов:     генераторы создают документы на основе информации, хранящейся в базах данных или просто в файловой системе;     XSLT-процессор применяет преобразования к сгенерированному документу;     сериализатор создает физическое представление результата преобразования.

В качестве генератора документа вполне может выступать, к примеру, сервлет.

Цитата(Stampede @ 14.6.2005, 20:42)

Но как XSLT может помочь генерировать HTML?

У нас было сделано следующим образом - одна часть содержала информацию о том как рисовать. А вторая включала информацию. Т.е. шаблон и наполнение.

Информация из шаблона использовалась для рисования XML. Я сейчас очень точно не вспомню, но в XSL очень просто можно заменить какую-либо ветку на ветку в том же HTML. Например у тебя есть таг <checkbox>......</checkbox> и его можно поменять на HTML аналог буквально за одну строку. Я писал последний раз на XSL уже года 4 назад поэтому не могу вспомнить точно. Помню только, что делается это легко

Цитата(Stampede @ 14.6.2005, 20:42)

Пожалуйста, можно поподробнее? В чем заключалась задача? Я просто пытаюсь сообразить, как бы это выглядело на Java.

У нас на тот момент не было схем и проверить правильность построения XML было атруднительно. Проверки типа - количество пунктов в меню, количество строк и столцов в таблице, наличие заголовков. Я поищу, может найду старый код и покажу примеры.

По поводу спора за программирования на Java или XML/ Мое мнение - XML!
Особенностью Sun Java - то что она ввязалась в войну технологий с MS, а теперь еще и с IBM на базе открытого кода. Это мешает продуктивно работать. С другой стороны - XML прост в использовании - его все любят. А если наконец узаконят XML Shchema - то цены ему не будет с точки зрения интеропа.

Цитата(DUnload @ 13.7.2005, 07:45)

По поводу спора за программирования на Java или XML

Ну скажешь тоже...
XML - не язык программирования и программировать на XML ну никак не получиться, конечно можно посмотреть в сторону XSLT или чего-то похожего, всё таки это расширения XML но и они языками программирования не являются.

Цитата(DUnload @ 13.7.2005, 07:45)

А если наконец узаконят XML Shchema

А что в нём такого незаконного?

А что касается непосредственно Cocoon то он совсем не призван заменить Java servlets или что-то подобное работой XML/XSLT, он просто позволяет отделить логику этих преобразований от генерации XML.

Это сообщение отредактировал(а) 3,14 - 13.7.2005, 14:06

Что касается программирования на Java под Cocoon - там неплохой встроенный Java Script Debugger
Что касается реплики уважаемого 3.14 по поводу программирования, не хочу вступать в дискуссию с молодежью, я слишком стар для этого, но еще в книге Пратта - "Разработка языков программирования" от 197х года сказано - то что для одних является програмным кодом, для других - это набор данных - только из этой двойственности программного кода я и исходил в приверженности к XML. Сам же программирую на Java - с 1996 как она только появилась в виде первого Sun-овского JDK.
Отдельно
О парадигмах и подходах - если помните в начале 90 бурно обсуждалась проблема инкапсуляции(совместного хранения данных и кода) в рамках объектного подхода. Дальше - концепция встроенности - например Java процедуры в СУБД, или наоборот карманная (embedded) СУБД в приложение.
И теперь плавно переходим к SOAP заметте - всего лишь спецификация переноса объектов над транспортным протоколом - но в ней вся сила современного распределенного подхода к организации взаимодействия данные<>код - все ее потенциальные возможности трудно даже перечислить

• независимость
• перенос данных
• поддержка RPC
• возможность создания расширений по принципу плагинов

Да что говорить все нормальные деплоеры EJB - напр. в IBM WebSphere - пользуются для встраивания в контейнер распределенных объектов SOAP.
Да собственно и все, что хотелось сказать.
Надоело просто восторгаться примерчиками типа Хелло Уорлды!

Это сообщение отредактировал(а) DUnload - 14.7.2005, 07:01

Цитата

не хочу вступать в дискуссию с молодежью, я слишком стар для этого

(не могу удержаться)
кости не болят ещё? склероз не замучал?

Теперь по делу.
Вообще-то, имхо, стоит исходить исключительно из задачи. В некоторых случаях можно вполне обойтись Cocoon, что повысит производительность программистов и снизит стоимость разработки. В других же случаях, уверен, что господин DUnload окажется прав. Но нельзя ведь под все задачи пихать одни и те же методы и технологии.

Цитата(DUnload @ 14.7.2005, 06:12)

Что касается программирования на Java под Cocoon - там неплохой встроенный Java Script Debugger

Ну если Java Script Debugger, то это не Java. Java и Java Script разные вещи

Цитата(DUnload @ 14.7.2005, 06:12)

но еще в книге Пратта - "Разработка языков программирования" от 197х года сказано - то что для одних является програмным кодом, для других - это набор данных

М-да, поглядел что такое язык программирования, XSLT всё же туда относиться но никак не XML в чистом виде.

Цитата

Язы́к программи́рования — формальная знаковая система, предназначенная для описания алгоритмов в форме, которая удобна для исполнителя.

понятно что срдествами XML можно описать и алгоритмы, но непосрдественно к XML в целом это отношения иметь не будет.

Цитата(DUnload @ 14.7.2005, 06:12)

в начале 90 бурно обсуждалась проблема инкапсуляции(совместного хранения данных и кода) в рамках объектного подхода.

Сейчас стараются наоборот разделить их как можно сильнее, отдельно бизнес логика, отдельно работа с данными (те же хранимые процедуры), отдельно интерфесная часть (тот же Cocoon)

На мой взгляд XML, в частности тот же SOAP, это скорее концепции дял разработки программ, нежели средства.

Цитата(3)

На мой взгляд XML, в частности тот же SOAP, это скорее концепции дял разработки программ, нежели средства.

Может, имеется в виду SOA?

Цитата

Может, имеется в виду SOA?

Да

У меня давно выработался свой, профессиональный взгляд на определенные вещи. В конечном итоге все должно быть по возможности переносимо на любую, даже самую простую, как в случае наладонников платформу. И там вообще ничего кроме php и SOAP не годится. И пока везде в сети брендмауэры - НТТP транспорт. Уж как Corba была хороша или тот же Jini, а всеобщей поддержки так и не получили. Не пробиться через густые сети безопасности!
К стати о XSLT, . концепцию каскадных стилей попытались вывести на новый уровень.
Там в рамках XSLT целая гроздь технологических направлений работают, помимо самого XLS преобразования, который сам еще содержит встроенный FO - форматер, необходим XPath для выбора нужных фрагментов для обработки. В конечном итоге речь идет об использовании внешних контроллеров форматирования, будь то FOP, Batik и тд. в рамках конвейера Cocoon/ Lenya или отдельно от систем публикации и менеджера содержимого, если уж говорить по теме форума. И надо еще учитывать организацию самого потока XML на уровне парсера. Если мы иожем обработать документ в памяти, можно использовать DOM, но если это огромный поток, необходим SAX, соответствуя схеме обработки событий. Хотя суть одна - показываю на схеме елки
* |
*----* | DOM
*--------------* v
---------> SAX


Когда Стив Балмер говорил, что четвертая революция после перс. компьютеров, мышки с оконным интерф., Интернета, будет развитие XML технологий. ОН имел ввиду решение всего комплекса проблем, связанного с автономным програмным обеспечением Сети, работающем при минимальном участии людей! А XML трансформация - это лишь маленькая часть этой задачи. А Java Enterprise - это так одно название. Ну контейнер, с двумя интерфейсами - домашним и удаленным. Но почему это обязательно реализовывать в виде локальной виртуальной машины? Ентерпрайс - он же должен быть ВЕЗДЕ! Это может быть только ХМ(л) во всех его проявлениях, а Java место в системах точка-точка. Да вообщем то она так и запроектирована. Возьмите Ёксту - вот и все тайное оружие Sun против всех в сети.

Это сообщение отредактировал(а) DUnload - 16.7.2005, 06:18

Цитата(DUnload @ 15.7.2005, 05:57)

Я же сказал - в дискуссию вступать не собираюсь.

Ну не собираетесь, так не собираетесь. Жаль, конечно, я с интересом бы послушал аргументированный вариант другого планирования системы, да и на примеры бы тоже посмотрел.

Некоторое время назад работал в фирме W-Technologies. Разрабатывали систему для мобильных устройств. Наша группа отвечала за сервеную сторону. И вот как раз тут у нас XML и XSLT работал на полную катушку.

Т.е. приходит запрос от мобильника в виде URL. В нем есть UserID, ID приложения, которое требуется пользователю и доп. параметры. Наша часть принимает запрос, определяет, что за девайс сделал запрос и запускает нужную прикладуху. Та делает свою работу и возвращает результат в виде XML. И вот тут и начинает работать XSL. В зависимости от типа девайса XML может быть преобразован в HTML, WML и прочая. Концепция заключалась в том, что в XML существовало две части - интерфейсная, которая говорила о том, какие абстрактные визуальные элементы есть на экране, и вторая часть - контент для этих компонентов. Для каждого типа девайса был свой XSLT, который из этого абстрактного описания экрана делал что-то конкретное - визуализировал и отправлял уже готовый документ девайсу.

Понятно, что можно и обычными средствами сделать из XML визуальный вариант, но в случае с XSL это достаточно удобно - единый подход. Да и сами XSL получаются весьма похожими, особенно, если конечные документы имеют где-то одинаковый синтаксис. Те же HTML и HDML и PQA - помню различия были минимальные. Пожтому сами XSL были очень похожи.

Вчера ночью по России показывали просто гениальный фильм на этот счет - "Почтальон" с Кевином Костнером. Так там есть просто замечательная фраза. Когда юный Форт что главное в профессии - Почтальон отвечает "Главное оказаться в нужном месте точно в нужное время".
Фильм - вообще гениально показывает жизнь!
Когда то людям понадобилось, что бы информация свободно доходила до адресата и объеденяла сердца, а людям оставалось только верить, ждать и надеятся. И каждый в жизни - либо мешает этому, либо способствует. Вот сейчас существует Всемирная Сеть. Но она запросто может перестать служить по своему назначению, если люди встанут на пути распространения информации, не важно исходя из каких там принципов.
Как говорил один мой хороший знакомый - Интернет и информационное сообщество живет по закону "новой истерии". Вот кто-то свистнул - и все побежали за мячиком. Но движение нельзя прекращать. Надо чтобы люди чегото хотели и тратили на это время и денежные средства.
Вот америанский пример:
В 95 неважно откуда, может они это просто украли, МS выкинули на рынок Win95, распространив бета предварительно по сети. И все ожило, забурлило, всем вдруг понадобились быстрые интел процессоры - какой это дало толчек развития ПК представить трудно, в 93-94 появился WWW = я тогда как раз в Германии учился, так что Инету можно сказать учился у немцев. И вот что меня больше всего поразило - он нам на первом занятии говорит - Сейчас сходим в Техас, поработаем с их хостом, а потом = я пошлю сообщение в Москву другу, но вот из Москвы ответ придет только завтра - очень медленная связь! Это теперь я понимаю, что с Техасом он связывался через HTTP или GIOP/IIOP, а с Москвой - по SMTP. Но тогда то мы этого еще не знали, и разница в скорости получения ответов была шокирующей.=
Так вот появился всемирный поток данных на базе сети. Сразу же мощный скачек Интернет-технологий. Мы так сказать в начале пути и лет через пять - шесть вообще будет непонятен предмет дискусии - Java или ХМ(л) все сольется в единую - еще более мощную технологию.
Мы на Jug еще несколько лет назад пытались представить язык программирования будущего.
=Но надо учесть, что крупные игроки на рынке соответствующего сегмента - разработчики софта, не могут использовать все что им захочется, вынуждены готовить рынок заранее к приходу той или иной технологии и для этого существует венчур типа Google и независимые разработчики типа Open Source.=
Главное, чтобы это способствовало движению, развитию технологий передачи и обработки данных, а не препятствовало им.

прошу прощения если кто считает что я отклоняюсб от темы форума, но на самом деле хочу только дать дополнительную пищу для ума. Вот на мой взгляд, важная фраза.
--------------
страницы web являются универсальным средством коммуникации, такая же свобода у потребителей web страниц. платформа, используемая для публикаций, не связана жестко с платформой просмотра,(за исключением стандартных протоколов, таких как НТТР и HTML. модель оказалась весьма успешной и, вероятно существенно превысилавсе намерения своих создателей в CERN(Centre Europeen de Recherche Nucleaire).
универсальность парадигмы первоначально ограничивалась и была предназначена для людей.
поясню - человек публикует страницу, другой ее читает и применяет. эта концепция развивалась как на стороне публикации так и на стороне использования.
спец программы пауки просматривают страницы чтобы делать их индексирование и обзоры. тем не менее эти расширения модели расчитаны на взаимодействие людей.
теперь плавно переходим к модели веб служб.
они так же публикуются в web. НО! ОНИ ОБЕСПЕЧИВАЮТ КОММУТАЦИЮ МЕЖДУ ПРОГРАММАМИ И ПРОГРАММНЫМИ КОМПОНЕНТАМИ. т.е они настроены не на использование непосредственно людьми, но другими программами, при этом сохраняя достоинство модели публикации в web:
независимость от языка разработки и платформы развертывания.
Вот и давайте рассмотрим COCOON как универсальную систему web публикаций, с точки зрения расирения его в сторону публикации web служб

Сам рассматриваю Cocoon именно как средство создания сайта для ЛЮБЫХ клиентов, и с содержимым из любых форматов. Учить менеджеров писать рекламные статьи даже в FrontPage - задача не для слабонервных. Веб-дизайнеру на каждую статью объяснять, какая фраза с точки зрения маркетинга самая важная - тоже. Поэтому идеальная CMS, с моей точки зрения - набрал статью в Word, назвал файл по-русски, проводником положил в папку "сайт". Остальное - дело техники. т.е. Cocoon. Смотри хоть из браузера, хоть с мобильника - все отформатировано, причесано, ссылки корректны. Кое-какие мысли здесь : http://smirnov.org.ru/cocoon-jsf.html

Хотел бы заметить, что использование Cocoon - не только использование XSLT.
Cocoon - это мощный Web Application Development фреймворк.
Кроме как использование XSLT, он позволяет использовать другие технологии для трансформации данных, как например, STX (Streaming Transformation for XML).
Также он обладает другими "фичами", которые делают его очень привлекательным вариантом при разработке Web-приложения.
Прежде всего это относится к Cocoon Flow, в котором может быть описана логика перехода между Web-страницами в пределах некой обособленной части функциональности (например, создание нового пользователя).
Особенно приятно использовать Cocoon Flow совместно с Cocoon Forms, который предназначен для обработки форм и биндинга данных форм и бизнес-объектов.
Являясь Java-приложением, он также прекрасно интегрируется с другими Java технологиями и инструментами (FOP, Lucene, POI, Quartz и др).

Кто-нибудь работал с базами данных в Cocoon'e?

Почему при создании динамической XML на основе данных из соединения с базой через XSP, все запрошенные данные потоком (без приглашения) поступают к XSLT обработчику (в результате чего, в XSLT перестает работать рекурсия)?

Задача: отобразить данные из базы данных в древовидной структуре.

p.s. может это баг Cocoon'a?

Всё, сделал правда немного иначе... Теперь другой вопрос Как передавать параметры генератору XSP через sitemap - кто знает?

Цитата(beo2525 @ 28.10.2005, 15:00)

Всё, сделал правда немного иначе... Теперь другой вопрос  Как передавать параметры генератору XSP через sitemap - кто знает?

Ух, уже и забыл, что такое XSP

Если в sitemap-е есть параметр для XSP

<map:generate type="serverpages" src="my-page.xsp">
<map:parameter name="paramName" value="paramValue"/>
</map:generate>

то его вроде можно вытянуть в самом XSP при помощи

<util:get-sitemap-parameter name="paramName"/>

или

<xsp:expr>(parameters.getParameter("paramName", null))</xsp:expr>


А вообще XSP состоят в статусе "deprecated". Cocoon рекомендует (и я поддерживаю их рекомендацию ) использовать JX-темплейты

Цитата(beo2525 @ 27.10.2005, 11:10)

Кто-нибудь работал с базами данных в Cocoon'e? Почему при создании динамической XML на основе данных из соединения с базой через XSP, все запрошенные данные потоком (без приглашения) поступают к XSLT обработчику (в результате чего, в XSLT перестает работать рекурсия)? Задача: отобразить данные из базы данных в древовидной структуре. p.s. может это баг Cocoon'a?

Извиняюсь, я не совсем понял, в результате чего в XSLT перестала работать рекурсия.

Сама природа заставляет XSP-страницу при компиляции передаваться на XSLT-трансформацию. Сами XSP-страницы были созданы по аналогии с JSP страницами, и поэтому компиляция XSP-страницы является двухступенчатой: на первом этапе из тела XSP-страницы при помощи XSLT-преобразований на основании logicsheet-ов (которые являются теми же XSLT-темплейтами) генерится Java-код; на втором этапе код компилируется в Java-классы.
Может у Вас где ошибка закралась в код страницы.

А если у вас в pipeline после XSP-генератора объявлен XSLT-трансформер, то возможно, что ошибка именно в stilesheet-е XSLT-трансформера. Правда в этом случае XSP никакого отношения к нему не имеет.

Для того, чтобы разобраться, Вашего описания не достаточно. Если проблема все еще мучает, то укажите версию Cocoon-а, образец sitemap-а и XSP-страницы.

Более глобальный совет - использовать ORM-инструменты (Hibernate, OJB и т.д.) в связке с Cocoon Flow. Конечно, Cocoon также имеет свои встроенные средства доступа к данным (esql logicsheet для XSP, SQL-трансформер, "original" и "modular" actions), но они не являются ключевыми инструментами в Cocoon. Все они разрабатывались давно и поэтому имеют большой ряд недостатков по сравнению с ORM. Богу - богово

Спасибо vepeter! ты здорово помог с параметрами... кстати, указанные тобой данные, как мне кажется, плохо документированы? откуда у тебя такие глубокие познания?

Цитата(beo2525 @ 1.11.2005, 13:07)

Спасибо vepeter! ты здорово помог с параметрами... кстати, указанные тобой данные, как мне кажется, плохо документированы?

Проект Apache Cocoon страдает такими же болячками, как и другие open source проекты, и прежде всего - недостаток документации. Но дистрибутив Cocoon-а содержит кучу примеров по работе с различными компонентами фреймворка. Так что советую копнуть в них

Цитата(beo2525 @ 1.11.2005, 13:07)

откуда у тебя такие глубокие познания?

Скромно о себе могу сказать, что периодически (когда более интенсивно, когда менее) работаю с Cocoon в течение где-то 3-х лет. Так что если будут вопросы - велком, может и не всегда получится очень оперативно, но всегда буду рад попытаться дать какой-то совет

vepeter, дистрибутив немаленький но на сколько это возможно я полазил по ней вдоль и поперек. Cocoon поддерживает собственными средствами идентификацию пользователя через компонет <authentication-manager>, но каким образом, можно сделать соединение защищенным? Как мне кажется, придётся импортировать в Cocoon код подобный Пу Йоу Чонга или может есть более оптимальные решения.

Кто-нибудь знает как передавать параметры между sitemap, допустим из корневого каталога в подкаталог?

Лаадно, я все сделал, спасибо за содействие!

А можно ссылку где об этом говорится?

Если например заполняется форма и выбираются checkbox'сы, то как не используя XSP передать эти параметры в следующий pipeline? Ведь заранее их число не известно.

И еще вопрос. Если я использую свой класс, то вроде надо подключать его вот так
<xsp:page>
  <xsp:structure>
    <xsp:include>java.text.MuClass</xsp:include>
  </xsp:structure>
 
, но это почему-то не работает. Как вообще отлаживать XSP?