У меня давно выработался свой, профессиональный взгляд на определенные вещи. В конечном итоге все должно быть по возможности переносимо на любую, даже самую простую, как в случае наладонников платформу. И там вообще ничего кроме 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, допустим из корневого каталога в подкаталог?