C>Понимаете, на Perl'е вы будете писать что-то типа C>
C>print "<html><body>..."
C>
C>То есть просто выводить текст страницы.
Это прошлый век. Для перла полно шаблоннызх движков, начиная со старого доброго libxsl.
C>В Tapestry я буду собирать страницу из компонентов — примерно как это C>делается в Delphi или других RADах, но с учетом особенностей WWW. C>Догадываетесь как будет быстрее делать?
Быстрее взять ORM с DAL объектами, которые умеют выгоняться в DOM, на который мы
натравливаем закэшированные xsl шаблоны и плюем полученный html в веб.
Для обработки нехитрой бизнес-логики можно автоматически генерить биндинги
бизнес-объекты в любой приемлемый скриптовый язык, и не заморачиваться.
dmz wrote: > C>То есть просто выводить текст страницы. > Это прошлый век. Для перла полно шаблоннызх движков, начиная со старого > доброго libxsl.
А без разницы. Все равно вся та же текстовая замена. В случае с libxsl
еще и придется в valid xml все делать.
> C>В Tapestry я буду собирать страницу из компонентов — примерно как это > C>делается в Delphi или других RADах, но с учетом особенностей WWW. > C>Догадываетесь как будет быстрее делать? > Быстрее взять ORM с DAL объектами, которые умеют выгоняться в DOM, на > который мы > натравливаем закэшированные xsl шаблоны и плюем полученный html в веб.
Во-первых, я что-то говорил про неиспользование ORM? В той же Tapestry я
могу привязать таблицу к результату запроса в Hibernate, при этом то как
будут отображаться объекты я могу задать декларативно с помощью OGNL
(Object Graph Navigation Language).
Тупой прямой подход с XSL почти всегда не работает, так как кроме
отображения данных обычно надо еще и менять их как-то.
> Для обработки нехитрой бизнес-логики можно автоматически генерить биндинги > бизнес-объекты в любой приемлемый скриптовый язык, и не заморачиваться.
Все красиво на бумаге...
>> доброго libxsl. C>А без разницы. Все равно вся та же текстовая замена. В случае с libxsl C>еще и придется в valid xml все делать.
Автоматически мэппя объекты на DOM — получить невалидный xml надо
постараться.
C>Тупой прямой подход с XSL почти всегда не работает, так как кроме C>отображения данных обычно надо еще и менять их как-то.
Поменяли на этапе обработки запроса. Получили — поменяли — вывели, в чем проблема.
>> Для обработки нехитрой бизнес-логики можно автоматически генерить биндинги >> бизнес-объекты в любой приемлемый скриптовый язык, и не заморачиваться. C>Все красиво на бумаге...
Это работает.
dmz wrote: > C>А без разницы. Все равно вся та же текстовая замена. В случае с libxsl > C>еще и придется в valid xml все делать. > Автоматически мэппя объекты на DOM — получить невалидный xml надо > постараться.
Задача: отобразить результат запроса (100000 элементов) в таблице. Чем
вам тут DOM поможет в организации paging'а?
> C>Тупой прямой подход с XSL почти всегда не работает, так как кроме > C>отображения данных обычно надо еще и менять их как-то. > Поменяли на этапе обработки запроса. Получили — поменяли — вывели, в чем > проблема.
Пользователю надо предоставить интерфейс для работы с данными. Скажем,
таблица и при нажатии на строку таблицы переход на форму ее
редактирования. Чем здесь XSL поможет?
Здравствуйте, Cyberax, Вы писали:
>> C>Нет. Java будет уступать только если сам автор не знает Java. >> Попрошу уточнить: какой именно стаж нужен? C>Не знаю, все от программиста зависит. Ну обычно хотя бы пол-года.
Пол года мало. Я с 3 месяцами стажа даже в страшном сне не видел написание простого сайта на Java
C>Ну так кто мешает так делать с Java?
Очень много специфики. От хостина и до написания кода.
>> C>А вы думаете, что на простом (хотя Perl намного сложнее Java) языке >> C>проще делать сложные вещи? >> На простом языке проще делать простые вещи и сложнее сложные. На сложном >> языке сложно делать простые вещи и проще сложные. На ассемблере сложно >> делать любые вещи. C>Понимаете, на Perl'е вы будете писать что-то типа C>
C>print "<html><body>..."
C>
C>То есть просто выводить текст страницы.
Зачем? Для каждого из сайтов я сделал набор шаблонов в виде html-файлов. В шаблоны поместил метки, которые заменяю налету на данные и на выходе получаю готовые страницы. Пример:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>tag_title</TITLE>
<LINK href="/stylesheet.css" type=text/css rel=stylesheet>
</HEAD><BODY>
<H1>tag_header</H1>
<DIV class=path>tag_path</div>
<DIV class=body><DIV class=body3>tag_body</DIV></DIV>
</BODY></HTML>
То есть представление (html), данные (MySQL) и код (PHP/Perl) полностью разделены. В случае чего я меняю html-шаблон (вставляю рекламу, ссылки или меняю структуру страницы), а код не трогаю. Это намного удобнее, чем собирать html прямо в коде. Кроме того, это позволяет удалять из страниц лишние пробелы, табуляции и признаки конца строк, что уменьшает объём отдаваемого пользователю html ~ на 10%.
Всё это возможно на Java. И даже на С/С++. Но код будет длиннее и цикл "обнаружение бага-исправление-тестирование" будет удлинён на стадию "компиляция". С другой стороны, компиляция на Java позволяет быстрее вылавливать ошибки: для Perl и PHP приходится лазить в лог сайта и догадываться, что там произошло.
C>В Tapestry я буду собирать страницу из компонентов — примерно как это C>делается в Delphi или других RADах, но с учетом особенностей WWW. C>Догадываетесь как будет быстрее делать?
Для малых сайтов, естественно, через шаблоны. И нагляднее, и быстрее, и технология проще, и программисты дешевле, и менять вид сайта можно поручить дизайнеру. А функция замены подстроки в шаблоне во всех языках работает с одинаковой скоростью
Для крупных я бы брал ASP.NET + MS SQL или PHP + MySQL. Практика показывает, что почему-то основная масса средних и крупных сайтов создаётся именно на этих технологиях.
>> C>И скорость разработки на Java, кстати, получается быстрее чем в ASP.NET. >> C>Так как Tapestry ориентирован не на VB6-developers. >> Спорить не буду: не сравнивал и обзоров по сравнению этих языков в глаза >> не видел. C>Прямых обзоров не видел (написать, что ли?). Есть C>JSF vs ASP.NET C>http://www.codeguru.com/csharp/.net/net_general/toolsand3rdparty/article.php/c11139/ C>Tapestry vs JSF C>http://www.theserverside.com/articles/article.tss?l=JSFTapestry
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Зачем? Для каждого из сайтов я сделал набор шаблонов в виде html-файлов. В шаблоны поместил метки, которые заменяю налету на данные и на выходе получаю готовые страницы. Пример:
СШ>
СШ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
СШ><HTML><HEAD><TITLE>tag_title</TITLE>
СШ><LINK href="/stylesheet.css" type=text/css rel=stylesheet>
СШ></HEAD><BODY>
СШ><H1>tag_header</H1>
СШ><DIV class=path>tag_path</div>
СШ><DIV class=body><DIV class=body3>tag_body</DIV></DIV>
СШ></BODY></HTML>
СШ>
СШ>То есть представление (html), данные (MySQL) и код (PHP/Perl) полностью разделены. В случае чего я меняю html-шаблон (вставляю рекламу, ссылки или меняю структуру страницы), а код не трогаю. Это намного удобнее, чем собирать html прямо в коде. Кроме того, это позволяет удалять из страниц лишние пробелы, табуляции и признаки конца строк, что уменьшает объём отдаваемого пользователю html ~ на 10%.
Только лучше взять готовый smarty и не мучаться. Насчет замены строк там все круче. Он написанный html-шаблон переводит при первом использовании (изменения отслеживаются по дате шаблона и результата) в php код. Интерпретатор все равно быстрее. Плюс на халяву можно получить кэширование готовых страниц. А возможностей в языке шаблоном очень много, к тому легко пишутся расширения.
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Раньше — да. Сейчас там есть ООП, но какое-то жутко непривычное и странное (я С++-шник)
Нее... Это раньше было странное (мягко говоря). В PHP5 они наконец-то сделали по уму, почти "как у всех". Чего мне теперь дико не хватает — это компиляции с проверкой имен и прочего. Люблю я опечатываться, но не люблю, когда это поздно вылезает.
Слава Шевцов wrote: >> > C>Нет. Java будет уступать только если сам автор не знает Java. >> > Попрошу уточнить: какой именно стаж нужен? > C>Не знаю, все от программиста зависит. Ну обычно хотя бы пол-года. > Пол года мало. Я с 3 месяцами стажа даже в страшном сне не видел > написание простого сайта на Java
Если программист грамотный и со знанием web-технологий, то может и
нескольких недель хватить.
> C>То есть просто выводить текст страницы. > Зачем? Для каждого из сайтов я сделал набор шаблонов в виде html-файлов. > В шаблоны поместил метки, которые заменяю налету на данные и на выходе > получаю готовые страницы.
А без разницы. Вот, предположим, у вас задача — сделать страницу с двумя
прокручиваемыми списками (то есть размазаных на несколько web-страниц с
кнопками "назад/вперед") по 200 экземпляров в каждом. Как вы это будете
делать? А если эти списки еще и редактируются?
Или другой вариант — сайт с конфигурируемыми личными виджетами. То есть
чтобы я мог себе сделать персональный вид с лентой новостей, свежими
голосованиями с RSDN и т.п. На Java делается элементарно — на PHP/Perl
придется это делать врукопашную.
> То есть представление (html), данные (MySQL) и код (PHP/Perl) полностью > разделены.
В данном примере они просто отделены по разным файлам, но все равно связаны.
> Всё это возможно на Java. И даже на С/С++. Но код будет длиннее и цикл > "обнаружение бага-исправление-тестирование" будет удлинён на стадию > "компиляция".
Нет, на Java данный пример будет выглядеть так:
<%@ page contentType="text/html" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>tag_title</TITLE>
<LINK href="/stylesheet.css" type=text/css rel=stylesheet>
</HEAD><BODY>
<H1><%=tag_header></H1>
<DIV class=path><%=tag_path></div>
<DIV class=body><DIV class=body3><%=tag_body></DIV></DIV>
</BODY></HTML>
Это "вывернутый" код на Java, при первом посещении страница компилится в
байт-код и выполняется. Большинство app-серверов поддерживают
автоматическую перекомпиляцию при изменении.
Но тут уже получается гораздо интереснее, например, я могу сделать так:
<%@ page contentType="text/html" %>
<%@ taglib prefix="o" uri="http://elewise.com/components/core"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>tag_title</TITLE>
<LINK href="/stylesheet.css" type=text/css rel=stylesheet>
</HEAD><BODY>
<H1><%=tag_header></H1>
<DIV class=path><%=tag_path></div>
<DIV class=body><DIV class=body3><o:scheduler
bind="cookie"/></DIV></DIV>
</BODY></HTML>
Это магически вставит наш контрол дневника, который сохраняет данные в
пользователя в cookie (а можно привязать и к БД).
Контрол, естественно, не простой javascript, а достаточно сложный
компонент с большой частью на server-side.
> Для малых сайтов, естественно, через шаблоны. И нагляднее, и быстрее, и > технология проще, и программисты дешевле, и менять вид сайта можно > поручить дизайнеру. А функция замены подстроки в шаблоне во всех языках > работает с одинаковой скоростью
Кстати, файлы страниц Tapestry/JSF — это валидный HTML, который
замечательно правится дизайнерами.
> Для крупных я бы брал ASP.NET + MS SQL или PHP + MySQL. Практика > показывает, что почему-то основная масса средних и крупных сайтов > создаётся именно на этих технологиях.
ASP.NET — просто проPRен, технологически он не лучше Java.
С ASP.NET еще другая проблема — есть куча программистов, гордо пишущих
"Знание ASP.NET" в резюме. А на деле они просто умеют в дизайнере
перетаскивать кнопки, без понимания как оно все работает.
Здравствуйте, Cyberax, Вы писали:
C>Нет, на Java данный пример будет выглядеть так: C>
C><%@ page contentType="text/html" %>
C><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
C><HTML><HEAD><TITLE>tag_title</TITLE>
C><LINK href="/stylesheet.css" type=text/css rel=stylesheet>
C></HEAD><BODY>
C><H1><%=tag_header></H1>
C><DIV class=path><%=tag_path></div>
C><DIV class=body><DIV class=body3><%=tag_body></DIV></DIV>
C></BODY></HTML>
C>
C>Это "вывернутый" код на Java, при первом посещении страница компилится в C>байт-код и выполняется. Большинство app-серверов поддерживают C>автоматическую перекомпиляцию при изменении.
C>Но тут уже получается гораздо интереснее, например, я могу сделать так: C>
C><%@ page contentType="text/html" %>
C><%@ taglib prefix="o" uri="http://elewise.com/components/core"%>
C><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
C><HTML><HEAD><TITLE>tag_title</TITLE>
C><LINK href="/stylesheet.css" type=text/css rel=stylesheet>
C></HEAD><BODY>
C><H1><%=tag_header></H1>
C><DIV class=path><%=tag_path></div>
C><DIV class=body><DIV class=body3><o:scheduler
C>bind="cookie"/></DIV></DIV>
C></BODY></HTML>
C>
C>Это магически вставит наш контрол дневника, который сохраняет данные в C>пользователя в cookie (а можно привязать и к БД).
C>Контрол, естественно, не простой javascript, а достаточно сложный C>компонент с большой частью на server-side.
Очень похоже на smarty в php. Разве что готовой достаточно большой библиотеки контролов нет (если я правильно понял про таглиб), точнее я не встречал. В том числе с компиляцией при первом обращении. По-моему твои проблемы в php надуманы. У меня не работает неправильно написанный пхп код — это не причина ругать пхп. Под java/asp есть удобные библиотеки — это не значит, что их нет в php. Если уж ругать какой-либо язык, то надо знать положение дел в нем.
__MasteR__ wrote: > C>Контрол, естественно, не простой javascript, а достаточно сложный > C>компонент с большой частью на server-side. > Очень похоже на smarty в php.
Даже близко не похоже. Smarty — это template-движок, хотя и очень
мощный. В Java есть симметричный ответ для него — Jakarta Velocity.
JSF — это _компонентный_ фреймоворк. То есть когда я пишу контрол (тот
же scheduler), то я могу привзывать к нему обработчики события.
К форме на странице привязана модель данных. Если пользователь жмет на
странице кнопку, то сабмитится форма, а на сервере вызывается
соответствующий обработчик события нажатия на кнопку. В обработичке я
могу поменять что-то в модели страницы и вернуться на страницу (или
перейти на другую), при этом измененные данные отобразятся в браузере
пользователя.
Все это сделано в виде достаточно абстрактного механизма, с кучей
полезных довесок. Например, я могу декларативно поставить валидаторы на
поля, которые сначала будут проверять правильность ввода в JavaScript'е
(чтобы лишний раз форму не посылать) _и_ перед изменением данных модели
уже на сервере.
Кстати, есть еще и другие интересные подходы к Web'у — представление
навигации в виде continuation'ов. На эту тему можно посмотреть Apache
Cocoon или Seaside (http://www.seaside.st/) для Smalltalk.
Здравствуйте, Cyberax, Вы писали:
>> C>А без разницы. Все равно вся та же текстовая замена. В случае с libxsl >> C>еще и придется в valid xml все делать. >> Автоматически мэппя объекты на DOM — получить невалидный xml надо >> постараться. C>Задача: отобразить результат запроса (100000 элементов) в таблице. Чем C>вам тут DOM поможет в организации paging'а?
Он заставит задуматся о рациональности вывода 100 000 элементов в одной таблице на одной странице.
Здравствуйте, __MasteR__, Вы писали:
СШ>>То есть представление (html), данные (MySQL) и код (PHP/Perl) полностью разделены. В случае чего я меняю html-шаблон (вставляю рекламу, ссылки или меняю структуру страницы), а код не трогаю. Это намного удобнее, чем собирать html прямо в коде. Кроме того, это позволяет удалять из страниц лишние пробелы, табуляции и признаки конца строк, что уменьшает объём отдаваемого пользователю html ~ на 10%.
__M>Только лучше взять готовый smarty и не мучаться. Насчет замены строк там все круче. Он написанный html-шаблон переводит при первом использовании (изменения отслеживаются по дате шаблона и результата) в php код. Интерпретатор все равно быстрее. Плюс на халяву можно получить кэширование готовых страниц. А возможностей в языке шаблоном очень много, к тому легко пишутся расширения.
Согласен. Минус лишь в том, что за это придётся заплатить временем на обучение. Хотя кеширование это значительный плюс при больших нагрузках.
Слава Шевцов wrote: >> > Автоматически мэппя объекты на DOM — получить невалидный xml надо >> > постараться. > C>Задача: отобразить результат запроса (100000 элементов) в таблице. Чем > C>вам тут DOM поможет в организации paging'а? > Он заставит задуматся о рациональности вывода 100 000 элементов в одной > таблице на одной странице.
Кто говорит про одну страницу? Одновременно видимо 20-100 записей.
Стандартный вариант — большая база, в которой можно делать поиск.
Результат поиска может быть достаточно большой.
Здравствуйте, Cyberax, Вы писали:
C>Задача: отобразить результат запроса (100000 элементов) в таблице. Чем вам тут DOM поможет в организации paging'а? C>Стандартный вариант — большая база, в которой можно делать поиск. Результат поиска может быть достаточно большой.
Можно поподробнее, как это делается на Java? ИМХО задача разбивается на следующие:
1. Выборка из базы подмножества для страницы. Если мне нужно разбивать по страницам результаты сложного запроса, то я так или иначе должен буду указать "select .... limit N,M" (мускуль, прости господи), или что-то аналогичное, будь то java или не java. То есть, эта работа в любом случае ложится на SQL сервер. Так?
2. Форматированный вывод rowset в таблицу. Тут возможно существование всяких удобных заготовок для таблиц, с подсветкой, например, четных/нечетных/текущих строк/столбцов и т.п. Хотя эти вещи достаточно легко и очень гибко делаются на XSLT, при отсутствии зависимости от фиксированного набора заготовок.
3. Формат URL и контролы для постраничной навигации. Могут очень сильно отличаться от проекта к проекту, от дизайна к дизайну. Разве можно свести всё возможное многообразие к чему-то более общему, чем обычный шаблонизатор?
Страница {pageno} из {pagecount}. Строк всего {rowcount}, на странице {pagesize}....
Дм.Григорьев wrote: > 1. *Выборка из базы подмножества для страницы.* Если мне нужно разбивать > по страницам результаты сложного запроса, то я так или иначе должен буду > указать "select .... limit N,M" (мускуль, прости господи), или что-то > аналогичное, будь то java или не java. То есть, эта работа в любом > случае ложится на SQL сервер. Так?
Да. Как вариант — результаты запроса целиком кэшируются на сервере, это
имеет смысл, если запрос не может быть тривиально разделен на страницы.
> 2. *Форматированный вывод rowset в таблицу.* Тут возможно существование > всяких удобных заготовок для таблиц, с подсветкой, например, > четных/нечетных/текущих строк/столбцов и т.п. Хотя эти вещи достаточно > легко и очень гибко делаются на XSLT, при отсутствии зависимости от > фиксированного набора заготовок.
Во-первых, в таблице можно отображать _любые_ объекты. В том числе и
набор колонок из запроса, отображением можно управлять практически как
угодно (в том числе и с помощью XSLT).
> 3. *Формат URL и контролы для постраничной навигации.* Могут очень > сильно отличаться от проекта к проекту, от дизайна к дизайну. Разве > можно свести всё возможное многообразие к чему-то более общему, чем > обычный шаблонизатор?
Можно, в этом-то все и дело. Tapestry/JSF настолько гибкие, что с их
помощью можно практически любой дизайн отобразить. Ну а если что-то уж
совсем странное нужно — то всегда можно спуститься на уровень
непосредственной генерации HTML.
Например, Tapestry/JSF поддерживают кастомизируемые парсеры URLов и
короткие URLы, прозрачно поддерживаются сессии. Недавно в Tapestry
начали добавлять поддержку forked sessions.
> Страница {pageno} из {pagecount}. Строк всего {rowcount}, на странице {pagesize}....
А в виде набора иерархических табов нарисовать?
Спасибо. Ещё один вопрос — требования к софту на сервере (Apache/Linux). В частности, нужны ли какие-либо службы (Tomcat, etc), или же это всё может стартовать как CGI, или можно по-всякому?
Дм.Григорьев wrote: > Спасибо. Ещё один вопрос — требования к софту на сервере (Apache/Linux). > В частности, нужны ли какие-либо службы (Tomcat, etc), или же это всё > может стартовать как CGI, или можно по-всякому?
Нужен какой-нибудь сервер приложений. Из свободный самый лучший — Tomcat.
Tomcat может работать как полностью автономный web-сервер (рекомендую
начать с этого), так и может работать в связке с Apache'ем с помощью
специального модуля (mod_ajp, если мне склероз не изменяет). При этом
Apache используется для выдачи статического контента, модули есть для
серий 1.3 и 2.х.
При _большом_ желании можно использовать JSP-страницы как CGI, но лучше
так не делать.
Для связи с базой используется JDBC (Java DataBase Connectivity). Для
всех нормальных баз (Oracle, MySQL, Postgres, SapDB, FireBird...)
драйвера JDBC идут в комплекте с самой базой. Есть одно исключение — для
MSSQL официальные JDBC-драйвера появились только недавно.
Здравствуйте, Cyberax, Вы писали:
C>Дм.Григорьев wrote: >> Спасибо. Ещё один вопрос — требования к софту на сервере (Apache/Linux). >> В частности, нужны ли какие-либо службы (Tomcat, etc), или же это всё >> может стартовать как CGI, или можно по-всякому? C>Нужен какой-нибудь сервер приложений. Из свободный самый лучший — Tomcat.
Томкат — только сервлет контейнер... Если говорить о лучшем бесплатном сервере приложений, то я бы назвал JBoss.
C>JSF — это _компонентный_ фреймоворк. То есть когда я пишу контрол (тот C>же scheduler), то я могу привзывать к нему обработчики события.
C>К форме на странице привязана модель данных. Если пользователь жмет на C>странице кнопку, то сабмитится форма, а на сервере вызывается C>соответствующий обработчик события нажатия на кнопку. В обработичке я C>могу поменять что-то в модели страницы и вернуться на страницу (или C>перейти на другую), при этом измененные данные отобразятся в браузере C>пользователя.
СШ>Тоже не знаю. Транслятор компилит, при отладке не ругается. Но явно что-то не то. Кстати, опустить знак $ я бы просто не додумался. Спасибо ты подсказал.
