Проблема наверняка тривиальная, но в лоб решения - не нашел и простой поиск ничего не дал
Динамически сгенерированная с большим количеством различных элементов jsp страничка html - внутри похожа на кашу на месте <% %>, <%@ %> и т.п. - пустые строки, проблелы и т.д. Дизайнер, который разработал статический макет - в динамическом результате уже ничего понять не может
Можно ли как то настроить Tomcat, чтобы страница html доформатировалась на выходе? Либо необходимо писать свой фильтр форматирования response'а? Наверняка ведь есть типовые методы решения такой проблемы

Именно этому посвящены JSTL, Velocity framework, Struts framework и прочее. Поищи на форуме, и загляни в FAQ - у нас есть первичная информация по этим технологиям (как минимум, по Velocity). А вкратце - нельзя доводить свои страницы до такого состояния

Наверняка Maksym имел ввиду другое. На самом деле результат парсинга JSP в HTML выглядит безобразно. Сужу в первую очередь по опыту общения с тэгами Struts и тем что генерируется в результате. И боюсь что простого решения проблемы нет. Хотя анализировать результат приходится не так часто и, думаю, с этим можно смириться.

Это сообщение отредактировал(а) tux - 9.10.2005, 08:50

Lamer George
Да, tux прав. Я немного другое имел в виду. Изначальная JSP с использованием bean'ов, include'ов, тэгов выглядит неплохо: понятно и красиво отформатирована А вот html код, дошедший до клиента в его броузер, - отформатирован уже плохо (за счет исключения всех управляющих конструкуций) - пустые строки, пробелы, табы (выше писал).
Решением в лоб вижу написание фильтра, который бы из responsе'а исключал все незначащие строки и улучшал форматирование ... или я первый кому это мешает..? не хочется изменять(читай ухудшать) форматирование JSP, чтобы получить более красивый конечный html...

Извиняюсь, не понял сразу.

Tomcat таких свойств, кажется, не имеет, да и не должен, по идее... Наверное, только вручную. Но если пустые строки можно исключить, то как, например, скорректировать отступы?


А это действительно такая насущная задача? Имхо, результирующие страницы не так часто приходится смотреть...

Lamer George
Ситуация простая. Сторонняя компания разработала дизайн и верстку html страниц. Теперь они смотрят динамизированную версию системы и пишут баг-репорты по испорченным местам html... где-то <BR /> забыли.. где-то JavaScript неправильно подключили...
И их прекрасно форматированные, аскетичные странички настолько переколбасились нашим JSP и т.п., что разбирать их занимает слишком много времени, особенно, когда где-то что-то разлазиться в таблицах. Приходится сначала вручную всю сохраненную страницу форматировать.
Вот так, в общих чертах

По результатам обсуждения назрел вопрос
Как правильно перехватит поток вывода у response'а в фильтре, построчно пробежать, и грамотно передать дальше?

Цитата(Maksym @ 10.10.2005, 14:26)

Как правильно перехватит поток вывода у response'а в фильтре, построчно пробежать, и грамотно передать дальше?

C томкатом идет пример compressionFilter - его гляньте.

pvo
В каком разделе? Ни в JSP Samples, ни в Servlet Examples (то что видно из Tomcat Web Application Manager) фильтров не наблюдаю

Maksym
webapps/servlets-examples/WEB-INF/classes/compressionFilters

Подождите, не вижу смысла форматировать HTML на строне сервера, если уж нужно посмотреть сгенерированный HTML документ, открыл его в нормальном редакторе, на сколько я помню, многие из редакторов сами умеют форматировать текст для просмотра.

3,14
Даже если отбросить в сторону проблему удобства просмотра html (редакторы то форматируют, но не совсем так как создатели кода, ориентироваться все равно сложновато) - остается проблема пустых строк, пробелов лишних. Это же накапливаются килобайты бессмысленного трафика !

Да и вообще, ощущение легкой кривоватости результата, даже при внешне идеальной работе, - остается

Цитата(Maksym @ 19.10.2005, 17:41)

Да и вообще, ощущение легкой кривоватости результата, даже при внешне идеальной работе, - остается

А при криво написанном фильтре будет ощущение кривоватости, а кривоватость - например все притормаживать будет . Согласен с 3,14 - стоит или пользоваться редактором для форматирования, или делать отдельную программу для форматирования.