А то вот начал со struts и JSP, а по статье Stampede о Velocity эта "технология"
must die.

так велосити - это ж вроде как бы template engine

а не webapp framework

Можно посмотреть еще Spring - http://www.springframework.org

Цитата(Slanix @ 20.9.2005, 13:30)

а по статье Stampede о Velocity эта "технология" must die

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

Во-первых, о Struts я вообще даже не заикался. Во-вторых, говоря о JSP, я не употреблял столь сильных выражений как "must die". Напротив, в одном месте в статье я специально делаю оговорку:

Цитата

На самом деле JSP вполне можно приспособить в качестве удовлетворительной вью технологии

То есть я хочу еще раз подчеркнуть: технология JSP не столько плоха сама по себе, сколько плохи те способы ее использования, которые она сама навязывает своей как бы простотой. Если же абстрагироваться от ее скриптовых возможностей, и сознательно ограничить себя в использовании JSP исключительно как средства рендеринга HTML кода, то в таком качестве страница JSP практически ничем не будет отличаться от шаблона Velocity (с точностью до синтакиса).

Но для реализации такого подхода нужна строгая программистская дисциплина и наличие какого-никакого фреймворка. Одним из таких фреймворков, кстати, вполне может быть тот же Struts (хотя я с ним реально не работал).

Лично я в своих веб приложениях пользуюсь доморощеным фреймворком, который меня вполне устраивает во всех отношениях: в плане удобства разработки, функциональных возможностей, расширяемости, быстродействия и пр.

Если интересно, могу в общих чертах рассказать.

Цитата(Stampede @ 20.9.2005, 21:06)

Если интересно, могу в общих чертах рассказать.

Мне - интересно. Чем он лучше сторонних фреймворков?

Цитата(Lamer @ 20.9.2005, 21:38)

Мне - интересно. Чем он лучше сторонних фреймворков?

Лучше - в первую очередь тем, что так мне не приходится учить чужие теги конфигурации

Шютка. В которой, как известно, есть доля шутки. На самом деле причина в следующем. Как я уже неоднократно замечал в разных тредах, для меня самая главная привлекательная особенность Java как среды для разработки веб приложений заключается в том, что она позволяет (по крайней мере в теории) проектировать сервер приложения без оглядки на веб-интерфейс.

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

Поэтому, натрахавшись с самыми разными неуклюжими технологиями ремоутинга, я как никто другой ценю наличествующую в Java возможность описать внешнюю функциональность серверной системы в виде набора интерфейсов - то есть перечня функций, которые эта система может выполнять для внешнего мира, как-то: завести аккаунт, совершить транзакцию, выдать список объектов, удовлетворяющих заданному критерию, и т. д.

А теперь о фреймворках. Тут есть один очень важный момент. Любой фреймворк по большому счету представляет из себя систему абстракций, то есть понятий, которыми он оперирует. Так, систему на Struts можно описать в терминах Actions, Action Forms и FormBeans. Систему на Cocoon - в терминах Pipelines и Transformers. Так вот, с позиций моего видения серверного приложения как черного ящика, который наделен некой объявленной функциональностью, это - совершенно неадекватные модели. Так, в первой из-под колпака отчетливо торчат уши веб-запросного цикла обслуживания, а во втором - ориентированность на преобразование в ущерб транзакционной семантике.

Поэтому, посмотрев вокруг и не обнаружив ничего такого, что вписывалось бы в мою концепцию, я (в который уже раз в своей жизни - см. подпись) нехорошо выругался и сел разрабатывать свою собственную модель. В результате у меня получилсся фреймворк, построенный вокруг трех основных концептов: Manager, Descriptor и Service.

Manager - это программный компонент, который отвечает за создание, выборку, обновление и кеширование объектов определенного типа. Например, менеджер юзеров или менеджер документов.

Descriptor - это компонент, представляющий бизнес-сущность.

Service - это компонент, реализующий последовательность обращений к менеджерам в транзакционном контексте для выполнения бизнес-метода.

Все, в таком виде систему можно запускать, тестировать и использовать без всякого веб контейнера - например, через толстого клиента или из тестового класса.

Помимо этого, для доступа к функциям приложения через веб-клиента у меня есть понятие Worker и Page.

Worker - это компонент, который отрабатывает веб-запрос. Возникает вопрос, почему не сервлет? Ну, к сервлетам в этом отношении у меня есть несколько претензий. Во-первых, очень бедные возможности маппинга. Если структура сайта простая (типа когда все ресурсы получают по адресу вроде index.php?article=12345), то и беды бы не было, но мне вот, например, больше нравятся ЧПУ (человеко-понятные УРЛ (с) Спектатор). Далее, мне не нравится, как реализован механизм переадресации сервлетов, и невнятный алгоритм обработки в случае возникновения ошибки. Не нравится, что response.outputStream намертво приделан к сокетам, из-за чего, скажем, реализовать буферированный вывод получается только ценой совершенно ненужных ухищрений.

В общем, у меня есть свой диспетчер, который по адресу ресурса находит Worker нужного типа и передает ему все полномочия по выполнению запроса. Воркер извлекает параметры, делает все что требуется и накапливает всю необходимую для окончательного рендеринга страницы информацию в объекте типа Page.

Под конец заполенная Page возвращается главному сервлету, тот сливает содержащиеся в нем данные с указанным шаблоном, делает необходимые пост-процессинговые манипуляции (например, прогоняет через "кавычкер") и отдает браузеру.

Вот так вот примерно устроен мой фреймворк. Прошу обратить внимание: я никому ничего не навязываю. В конце концов, миллионы веб сайтов построены на готовых решениях - и ничего, работают, не разваливаются. У меня есть идея оформить мой фреймворк в виде опен-сорсного проекта. Думаю, найдутся люди, которым мой взгляд на веб-приложение окажется ближе, нежели какой-либо другой. Но для этого он пока еще сильно сырой, плюс есть у меня на данном этапе и более амбициозные задачи. Так что, как говорится, поживем-увидим.

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

Stampede, приношу свои глубочайшие извинения.

Немного запутался во всех этих Struts, Spring, Velocity, JSP, JSF.
Что с чем и как использовать? И что лучше?
Хотелось бы остановится на каком-то красивом решении для разработки webapp.

Цитата(Slanix @ 21.9.2005, 06:06)

Хотелось бы остановится на каком-то красивом решении для разработки webapp.

Давай, ты попробуешь Spring, как советовал AntonSaburov, а потом расскажешь нам, что из этого получилось. Лично у меня есть ощущение, что это правильная технология

Хочу поднять старую тему :-)
С полгода назад появилась задача сделать первое в жизни WebApplication. Сразу ринулся в изучение правильных технологий. Начал с velovity. Потом было JSF
Вот на нем хотел бы остановиться по-подробнее.
Сразу скажу, что не понравилось в этой технологии - непонятная чехарда с URL. Ни о каком ЧПУ речи даже не идет. Если нужно, что бы УРЛ текущей страницы был адекватно связан с содержимым - необходимо во всех переходах ставить redirect. В противном случае, после сабмита формы вы остаетесь на старой странице, если смотреть УРЛ, а судя по содержанию - переместились на  другую страницу.
Второе, вся работа приложения построена на javascript и POST запросах. Прямого способа сделать закладку на некоторую страницу внутри приложения я не нашел :-(

И еще, не касаясь JSF. Понадобилось интегрировать в небольшое приложение контроль доступа с авторизацией. Внятного способа контроля доступа не нашли. Вполне может быть, что плохо искали. 

sandello, а как сейчас дела обстоят? Твое мнение не поменялось о JSF?

Неа. Мы от него отказались нафиг :-)
Используем Struts