Увы, нет. При обращении по УРЛу, который заканчивается на слэш (т. е. представляет директорию), контейнер таки пытается физически залезть в эту директорию и найти один из файлов, прописанных в welcome-file-list.

2 diablero: Предлагаю для простоты обойтись для начала шаблоном, в котором будут постоянные шапка, левое меню навигации и подвал. Чтобы сильно не страдать, можешь сверстать это таблицей.

И это, я надеюсь, твой HTML содержит только структурную разметку, а внешний вид ты задаешь через CSS.

Скажите, а i18n не будет? Очень бы хотелось посмотреть.

Так и сделал. 

Это сообщение отредактировал(а) diablero - 23.7.2007, 18:31

Присоединённый файл ( Кол-во скачиваний: 102 )
 home.vm 1,70 Kb

И то это не главная страница. Нам нужно выделить в отдельный класс создание каркаса. Т.е. как бы статическое содержимое для всех страниц, кроме тех которые касаются учетной записи.
Т.е. два каркаса. И нужно еще создать таблицу в базе section

diablero
Скажи пожалуйста, куда ты положил persistence.xml, так чтобы при инициализации из сервлет-контейнера после деплоймента EntityManagerFactory его нашла?
И, если несложно, всопроизведи структуру каталогов, которая сейчас получилась в проекте.. 

Так, отлично! (на самом деле есть замечания, но пока ладно) Теперь внимание: сейчас мы резко упростим код и уберем повторяющиеся элементы в шаблонах. Для этого мы воспользуемся конструкцией Velocity #parse. Там, где у тебя стоит элемент <td> для основного контента, пишем:



Теперь обязанность каждого воркера - положить в контекст Velocity имя соответствующего шаблона под ключом "content". Например, в ArticleWorker:



Соответственно, из article.vm убираем все лишнее и оставляем только то, что составляет информационный блок страницы.

Сам шаблон страницы (который ты запостил под именем home.vm), переименовываем в, скажем, template.vm - это будет наш единый шаблон для всех страниц сайта.

Также поменяем сигнатуру метода Template getTemplate() в интерфейсе Worker на вот такое:



Поскольку, как мы только что решили, шаблон у нас будет один и тот же, есть смысл реализовать этот метод раз и навсегда для всех воркеров. Для этого создаем базовый абстрактный класс:



И тогда в остальных воркерах (наследуемых от AbstractWorker), нам останется только реализовать метод execute().

При этом работу по получению экземпляра Template по имени придется, естественно, перенести в метод service() сервлета-контроллера, но это как раз хорошо: нечего воркерам иметь дело с TemplateManager.

Все, мы уже почти готовы подвести четвертую жЫрную черту. Таблицу для секций пока не создавай. Определи простой бин Section, напиши SectionManager, а в его методе инит зашей прямо в коде создание нескольких экземпляров Section.

Да, вот еще: во всех бинах определи метод getUrl(), примерно такого содержания:



После всего этого у тебя получится практически действующий сайт (правда, пока только в режиме просмотра).

2 Ulysses4j:



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

to Maksym

В META-INF, посмотри во вложении структуру

Присоединённый файл ( Кол-во скачиваний: 132 )
 _________.jpg 34,00 Kb

diablero

Спасибо, все понятно, все работает.

Maksym, а ты, выходит, тоже активно следишь за сериалом? Интересно было бы услышать твое мнение - с учетом предыдущего (if any) опыта веб разработки и в свете твоих вебных планов.

Stampede
Когда ты говорил о ЧПУ ты держал в уме некоторый механизм, который позволил бы реализовать его внутри нашего приложения? Если да, то опиши его, пожалуйста, в двух словах.

Добавлено @ 20:25

Слежу, можно сказать дышу diablero в затылок. Мнение пока формируется, как только созреет -- обязательно поделюсь.

Это сообщение отредактировал(а) Maksym - 23.7.2007, 20:28

Там на самом деле все достаточно просто. Представим, как могли бы выглядеть некоторые УРЛы:

• /articles/c++/, /articles/java/, /articles/python/ - разделы;
• /articles/java/Using-Regular-Expressions-In-XML.shtml - статья;
• /accounts/diabler.shtml - профиль юзера;
• и т. д.

Нагрузка тут ложится на два места: 

• В реализации метода getUrl() нужно закодировать, как по имени/заглавию сформировать соответствующий УРЛ. Можно в принципе делать это однократно, при создании объекта, и потом хранить как поле в базе.
  
• В реализации диспетчера, который по УРЛу выдает класс воркера. Там нужно предусмотреть какие-то конфигурируемые маппинги, желательно в формате, который предусматривает wildcards. Например, /articles/*/ - для всех страниц-разделов.

В остальном логика останется практически без изменений.

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

Stampede
Спасибо. Исходя из своего понимания того что ты сказал, только что попробовал на примитивном уровне, все красиво ложиться. Интересно, что с использованием, например, jsf подобный механизм так прозрачно не встроить.
Но мы еще не видели контроллера (буква C)...    

Добавлено через 9 минут и 15 секунд

Но для этого прийдется прописать такой мэпинг:

Как тогда быть с картинками, css-ами и прочими ресурсами, которые обычно отдаются напрямую.. тоже анализировать url..?

Молодец, верно подметил.

Один из выходов - в web.xml явно замапить картинки, css, js и пр. статические ресурсы на дефолтный контроллер, например, по расширениям.

Другой выход - забить вообще на встроенные средства и отдавать всю статику самому. Правда, для этого придется конфигурировать content-type. Зато появляются плюсы, такие как возможность при желании логировать, в рамках единого подхода, запросы к статике, тонко управлять кэшированием на клиенте, гзиповать вывод, и пр.



Да в общем-то, можно сказать, уже и видели: класс сервлета-контроллера и метод getWorkerClass(String url).

Вот тут мне не понятно. 
Наш алгорим действий:
1. В service() определяем имя шаблона, от воркера получаем контекст. И сливаем их вместе.
2. Полученный Template мы должны слить с template.vm.

Как выполнить второй пункт?

Нет, там все проще, чем ты думаешь:



А воркер нам как раз и вернет "template.vm".