Здравствуйте, skodnik, Вы писали:
S>Установил TomCat. По аналогии с апачем сначала долго искал — как же новый хост добавить, после часа "бубноюзания" вычитал, что если взять sample.war и задеплоить его на сервере, то у меня появится на сервере новый урл типа http://localhost:8080/sample где будет это приложение. (Ну и ладно, пусть не новый хост, пусть в подпапке)
S>Как показало приложение sample (в поставке томкета) оно может быть выполнено либо как JSP либо как servlet. S>Посему, уважаемые Java-гуру два вопроса: S>- Что посоветуете в первую очередь потрогать руками: JSP ^ servlet? S>- Может ли NetBeans (ну не рабоает у меня eclipse!) создавать WAR'ы?
Здравствуйте, skodnik, Вы писали:
S>Что интересно, ссылка на сервлет-приложение = http://localhost:8080/sample/hello S>но только я в папке с приложением не вижу hello, и вообще не пойму откуда томкет берет что-то для отображения
Установил TomCat. По аналогии с апачем сначала долго искал — как же новый хост добавить, после часа "бубноюзания" вычитал, что если взять sample.war и задеплоить его на сервере, то у меня появится на сервере новый урл типа http://localhost:8080/sample где будет это приложение. (Ну и ладно, пусть не новый хост, пусть в подпапке)
Как показало приложение sample (в поставке томкета) оно может быть выполнено либо как JSP либо как servlet.
Посему, уважаемые Java-гуру два вопроса:
— Что посоветуете в первую очередь потрогать руками: JSP ^ servlet?
— Может ли NetBeans (ну не рабоает у меня eclipse!) создавать WAR'ы?
Здравствуйте, skodnik, Вы писали:
S>- Что посоветуете в первую очередь потрогать руками: JSP ^ servlet?
JSP сразу нафиг.
S>- Может ли NetBeans (ну не рабоает у меня eclipse!) создавать WAR'ы?
Ant, Maven. Можно, кстати, WAR не архивировать а распакованым кидать. И почему NetBeans? Eclipse или Idea. И ешё. Смотрел на днях J2EE туториалы. Вроде для последних версий они стали очень не плохи. Раньше это были скриншоты с указаниями какие кнопки нажимать. Сейчас уже внятный код с описанием.
Здравствуйте, skodnik, Вы писали:
S>Установил TomCat....
Что интересно, ссылка на сервлет-приложение = http://localhost:8080/sample/hello
но только я в папке с приложением не вижу hello, и вообще не пойму откуда томкет берет что-то для отображения
"По запросу 'field(h1,Blazkowicz) JSP' найдено документов: 304"
Причем даже в теме 2005 года ты уже отсылаешь в поиск, чтобы найти твой более ранний ответ
Все-таки нашел:
B>1)Итак JSP страница компилируется в сервлет в результате получаем тормоза при перекидывание между страницами dispatch и всё такое.
Один раз при старте контейнера или при изменении JSP-страницы. Откуда тормоза в штатной работе?
И во что компилируется Freemarker или Velocity? Мне так казалось, что все в тот же сервлет.
B>Синтаксис. При первом взгляде на JSP человек с ним мало знакомый ужасается, особенно когда там активно используются TL, при первом взгляде на шаблон velocity человек видит родной B>HTML. И лишь небольшие различия. Это всё даёт огромный выигрышь в трудозатратах, сколько займеёт времени перегон HTML дизайна в Velocity и в JSP?
Немного есть. С другой стороны, я вник в JSP за пару дней, работая с ним время от времени. С другой стороны, JSP очень гибок, можно создавать свои TL, использовать уже готовые и т.д., и т.п. Как везде, чем гибче и универсальнее, тем более замороченная.
B>Громоздскость. И так сколько всего нужно знать чтобы освоить JSP + JSTL? Velocity осваивается за день почти полностью. А результат один — всё тот же HTML на выходе вэб приложение.
Сколько нужно знать? Не так уж и много. См. чуть выше.
B>Ещё о трудозатратах. Шаблоны Velocity можно менять в рантайме. Что опять же сууущественно облегчает отладку и саппорт. Попросит у тебя кастомер на рабочем серваке внести некоторые B>небольшие изменения на странице. Сколько времени понадобиться для JSP? Или залить одну новую страницу Velocity...
JSP тоже компилируется на лету при изменении.
С другой стороны распространенность технологии и поддержка ведущими собаководами выливается в хренову тучу информации по всем возможным граблям, уже готовым библиотекам и фреймворкам.
Здравствуйте, Donz, Вы писали:
B>>http://img.meta.ua/rsdnsearch/?q=author%28Blazkowicz%29+JSP&mode=rank&group=N&group=10 D>"По запросу 'field(h1,Blazkowicz) JSP' найдено документов: 304"
По темам сразу видно холиварные.
D>Причем даже в теме 2005 года ты уже отсылаешь в поиск, чтобы найти твой более ранний ответ
Я такой.
D>Все-таки нашел: B>>1)Итак JSP страница компилируется в сервлет в результате получаем тормоза при перекидывание между страницами dispatch и всё такое. D>Один раз при старте контейнера или при изменении JSP-страницы.
Т.е. тормоза в дев-мод не оспариваются? Замена шаблона Velocity вооруженным глазом не видна. В продакшне автоматическай проверка изменения шаблона отключается, дабы работало быстрее.
D>Откуда тормоза в штатной работе?
В логике диспетчиризации запроса контейнером на кучу сервлетов (jsp) вместо одного-двух.
D>И во что компилируется Freemarker или Velocity? Мне так казалось, что все в тот же сервлет.
Ни во что не компилируется. Velocity работает удивительно шустро и без этого. Хотя с точки зрения Sun кодогенерация единственный путь для достижения максимальной производительности. Хотя, как показала практика, производительность последнее время ушла уже даже не на второй план. Стоимость поддержки кода намного дороже чем железа. Поэтому читабельность простота модификации и масштабируемость.
B>>Синтаксис. При первом взгляде на JSP человек с ним мало знакомый ужасается, особенно когда там активно используются TL, при первом взгляде на шаблон velocity человек видит родной B>HTML. И лишь небольшие различия. Это всё даёт огромный выигрышь в трудозатратах, сколько займеёт времени перегон HTML дизайна в Velocity и в JSP? D>Немного есть. С другой стороны, я вник в JSP за пару дней, работая с ним время от времени. С другой стороны, JSP очень гибок, можно создавать свои TL, использовать уже готовые и т.д., и т.п. Как везде, чем гибче и универсальнее, тем более замороченная.
Создавать свои TL это полный абзац. Дебажить их потом стороннему человеку будет не просто. И очевидно что читаемость самой страницы тут никак не выигрывает.
B>>Громоздскость. И так сколько всего нужно знать чтобы освоить JSP + JSTL? Velocity осваивается за день почти полностью. А результат один — всё тот же HTML на выходе вэб приложение. D>Сколько нужно знать? Не так уж и много. См. чуть выше.
Velocity сильно проще JSP. Tapestry и Wicket шаблоны более похожи на HTML отчего их читать одно удовольствие.
B>>Ещё о трудозатратах. Шаблоны Velocity можно менять в рантайме. Что опять же сууущественно облегчает отладку и саппорт. Попросит у тебя кастомер на рабочем серваке внести некоторые B>небольшие изменения на странице. Сколько времени понадобиться для JSP? Или залить одну новую страницу Velocity... D>JSP тоже компилируется на лету при изменении.
В течении полуминуты...
D>С другой стороны распространенность технологии и поддержка ведущими собаководами выливается в хренову тучу информации по всем возможным граблям, уже готовым библиотекам и фреймворкам.
JSP одна из немногих технологий которая как-то удерживает оборону атакующих со всех сторон opensource альтернатив. В основном благодаря тому что Killer WebApp Framework так и не появился. Все страдают какими-либо локальными проблемами.
Здравствуйте, Blazkowicz, Вы писали:
B>Т.е. тормоза в дев-мод не оспариваются? Замена шаблона Velocity вооруженным глазом не видна. В продакшне автоматическай проверка изменения шаблона отключается, дабы работало быстрее.
Не могу сравнить, про Velocity знания только теоретические. Но я бы не сказал, что изменение JSP сильно тормозило работу. То есть, я этого просто не замечал.
D>>Откуда тормоза в штатной работе? B>В логике диспетчиризации запроса контейнером на кучу сервлетов (jsp) вместо одного-двух.
Почему на кучу? Один запрошенный урл — в конечном счете один jsp. Или ты про includes?
D>>И во что компилируется Freemarker или Velocity? Мне так казалось, что все в тот же сервлет. B>Ни во что не компилируется. Velocity работает удивительно шустро и без этого. Хотя с точки зрения Sun кодогенерация единственный путь для достижения максимальной производительности. Хотя, как показала практика, производительность последнее время ушла уже даже не на второй план. Стоимость поддержки кода намного дороже чем железа. Поэтому читабельность простота модификации и масштабируемость.
Не очень понимаю. В конечном счете пользователь получает данные от сервлета, правильно? Или Velocity предоставляет свой контейнер? Я про свою реализацию контейнера на сайте проекта не нашел.
B>Создавать свои TL это полный абзац. Дебажить их потом стороннему человеку будет не просто. И очевидно что читаемость самой страницы тут никак не выигрывает.
Ну хз. Смотря как создавать. Как и к любой библиотеке нужна нормальная документация.
D>>JSP тоже компилируется на лету при изменении. B>В течении полуминуты...
Как уже сказал, какие-то особенные тормоза не запомнил. Но спорить не буду.
B>JSP одна из немногих технологий которая как-то удерживает оборону атакующих со всех сторон opensource альтернатив. В основном благодаря тому что Killer WebApp Framework так и не появился. Все страдают какими-либо локальными проблемами.
Немаленький такой плюс.
Здравствуйте, Donz, Вы писали:
D>Не могу сравнить, про Velocity знания только теоретические. Но я бы не сказал, что изменение JSP сильно тормозило работу. То есть, я этого просто не замечал.
Возможно что эта проблема в 2010 году уже и не так актуальна. JSP не трогал уже много лет.
D>>>Откуда тормоза в штатной работе? B>>В логике диспетчиризации запроса контейнером на кучу сервлетов (jsp) вместо одного-двух. D>Почему на кучу? Один запрошенный урл — в конечном счете один jsp. Или ты про includes?
Каждая jsp этот сервлет. Тормозит диспетчер сервлетов, выбирая, нужный сервлет. Опять же как и предыдущий пункт это тоже уже не суть важно.
B>>Ни во что не компилируется. Velocity работает удивительно шустро и без этого. Хотя с точки зрения Sun кодогенерация единственный путь для достижения максимальной производительности. Хотя, как показала практика, производительность последнее время ушла уже даже не на второй план. Стоимость поддержки кода намного дороже чем железа. Поэтому читабельность простота модификации и масштабируемость. D>Не очень понимаю. В конечном счете пользователь получает данные от сервлета, правильно? Или Velocity предоставляет свой контейнер? Я про свою реализацию контейнера на сайте проекта не нашел.
Не понял вопроса. Velocity — простейший движок шаблонов. Ни о каких контейнерах сервлетах и компиляции разговор не идет. Сейчас этот движок слегка устарел. Но это просот наглядный пример что есть вещи лучше чем JSP.
B>>JSP одна из немногих технологий которая как-то удерживает оборону атакующих со всех сторон opensource альтернатив. В основном благодаря тому что Killer WebApp Framework так и не появился. Все страдают какими-либо локальными проблемами. D>Немаленький такой плюс.
В чем плюс? Глобальных альтернатив сервлетам или JMS никто не порывается создавать, так как спецификации вполне себе самодостаточны. А вот свой формат шаблона для HTML порывается создать каждый приличный Web Framework и не потому что JSP так хорош.
Здравствуйте, Blazkowicz, Вы писали:
B>Каждая jsp этот сервлет. Тормозит диспетчер сервлетов, выбирая, нужный сервлет. Опять же как и предыдущий пункт это тоже уже не суть важно. B>Не понял вопроса. Velocity — простейший движок шаблонов. Ни о каких контейнерах сервлетах и компиляции разговор не идет. Сейчас этот движок слегка устарел. Но это просот наглядный пример что есть вещи лучше чем JSP.
Не понимаю, как взаимодействует Velocity и сервлеты. Есть ссылка на какую-либо диаграмму последовательности действий при запросе из браузера? Один шаблон велосити во что превращается в конечном итоге, разве не в сервлет в конечном случае? Кто разруливает, какой исходный шаблон брать в завимости от запроса? Диспатчеризация — это вообще к JSP относится, разве? Мне так казалось, что к самим сервлетам, вне зависимости от шаблонизатора.
Здравствуйте, Blazkowicz, Вы писали:
B>Не понял вопроса. Velocity — простейший движок шаблонов. Ни о каких контейнерах сервлетах и компиляции разговор не идет. Сейчас этот движок слегка устарел. Но это просот наглядный пример что есть вещи лучше чем JSP.
Вот именно, что простейший. Имея опыт работы с TAL мне хотелось поиметь в джаве что-то похожее, но проанализировав рынок я все же решил разобраться с JSP, и не пожалел! Мощный инструмент, веломаркеры даже и близко не валялись. И вполне простой, если его использовать как чистую вьюху. При том наезд на собственные теги необоснован — очень многое можно сделать с помощью тег-файлов, что очень хорошо ускоряет и упрощает работу. Перекомпиляция при локальной работе с jetty длится пару секунд, и это на моем далеко не самом быстром, и уже не новом ноуте.
Здравствуйте, skodnik, Вы писали:
S>Установил TomCat.
Прямой ответ:
Сразу ставь apache maven. Это сборщик проектов. А HelloWorld.war мавеном и делай.
mvn archetype:generate
и в портянке вариантов приложений выбрать maven-archetype-webapp (A simple Java web application)
обычно это номер 18, но в распоследней версии портянка удлиннилась раз в 5 и все съехало и продолжает съезжать
Ну и собственно
mvn package
чтобы получить сам варник.
А что касается IDE — лучше базироваться на проектах в формате мавена. Мавеновские проекты импортируются любой IDE на ура. От себя рекомендую IntelliJ Idea, а не netbeans.
