Не, я не это имел ввиду.
template.vm это наш базовый шаблон. Где есть такая строчка

Мы запрашиваем статью, в воркере статьи, мы заполняем контескт и сливаем его с post.vm.
Теперь нам нужно слить post.vm с template.vm. Вот я не пойму как это сделать

Так а это делается не сливанием в смысле merge. Просто когда движок Velocity дойдет до строчки #parse("$content"), он полезет в контекст, найдет там переменную "content", и использует ее как имя шаблона, который нужно включить в данном месте.

Как я уже говорил ранее, это забота воркера - заранее положить в контекст имя нужного шаблона:

Вопрос снят. 

Добавлено @ 22:28
А... Ту уже ответил 
Сейчас все выложу



Релиз кандидат четвертой жЫрной черты

Это сообщение отредактировал(а) diablero - 25.7.2007, 20:21

Присоединённый файл ( Кол-во скачиваний: 117 )
 Infinite1.1.3.4.zip 23,88 Kb

Поздравляю!

Разбор полетов - завтра. А пока - всем отдыхать 

Да и мне бы еще по работе чуток поработать 

Ну знач поехали.

1. Пора бы нам уже начать группировать классы по пакетам, а то куча уже большая получается. Напрмер, явно напрашиваются к выделению менеджеры, воркеры и data бины.

2. Есть несколько не совсем удачных имен, которые привносят путаницу.

• Например, почему Configuration превратилось в Settings?
• Или, например, интерфейс EngineManager. Я бы его вообще убрал, потому что он у нас недостаточно общий, поскольку имеет библиотечную зависимость, VelocityContext. Тут надо или вводить дополнительный слой абстракции для контекста, или отказываться от потуг сделать все в общем виде.
• Имя MainController не отражает того факта, что это все-таки в первую очередь сервлет. ControllerServlet было бы лучше.
• В web.xml для главного сервлета используется имя index.shtml. Это вводит в заблуждение, поскольку наводит на мысли о каких-то физических структурах.

3. Использование переменных в шаблоне.

Вот смотри, как у тебя сделан post.vm:



А ведь Velocity-то позволяет обращаться к полям бинов (имеющим соответствующие геттеры) напрямую! И получается, что нам всего-то нужно засунуть в контекст две переменные: user и article. Это резко сокращает вероятность ошибок типа недосмотров, опечаток и наложения имен. Шаблон будет выглядеть вот так:



Я убрал "версию для печати", потому что в наше время это делается гораздо проще, средствами CSS.

Ну и по-хорошему $user.name надо бы сделать ссылкой:



4. Ну и по мелочам:

• В infinite.sql отсутствует часть для Section.
• Код CSS надо все-таки как-то планировать, но это ладно, потом.
• При выставлении contentType в методе service() кодировку лучше брать все-таки из конфига - мы ж его для этого и предусматривали.

Может, еще что замечу/вспомню. Предлагаю подкорректировать по своему усмотрению и перезалить.

Создал бин News. И что бы не было путанницы, везде теперь фигурирует Post, а не Article. Классы по пакетам сгруппировал, может быть имя не совсем удачное выбрал?
Интерфейс EngineManager убрал, не думаю что откажусь от Velocity.
Еще посмотрю и проанализирую...
Перезалил.

Теперь уже вырисовыватся вполне ясная картина, и структура сайта. Рано или поздно я бы дошел до этого, или бы забил на пол пути Т.к. не встречал ни одной книги, где разъяснялась последовательность разработки, даже простого сайта. Как закончим, нужно будет это все оформить, но это все потом.

З.Ы. Попутно научился засыпать раньше чем закроются глаза

Да, и это заметно - например, по тому, как ты ловко добавил сущности Section и News, со всеми сопутствующими компонентами.

В целом структура кода уже почти окончательная. Единственное, мы немного изменим сигнатуру метода Worker.execute() и введем дополнительно несколько новых понятий - для пущего удобства. А сейчас приступаем к следующему этапу - аутентификации и авторизации доступа.

Как мы уже многократно убеждались, "книжные" подходы для нас, простых сайтостроителей, не годятся. Поэтому мы пойдем другим путем. А именно, возьмем на вооружение простую технику, веками используемую в мире ПХП - технику, основанную на куках. Для этого важно понимать, что такое куки, кем и когда они создаются, и как участвуют в коммуникации по HTTP. Чтобы иметь полную картину происходящего, рекомендуется скачать и установить плагин Firebug. Тогда на закладке Net будет видно, с точностью до буквы, что поылал браузер, и что приходило в ответ.

Итак, первым делом нам нужно залогиниться. Для этого где-нибудь в шапке страницы пропиши форму для ввода с полями login, password и кнопкой "Войти", метод POST. Атрибут action пусть указывает на такой УРЛ:

/submit/login.do

Здесь .do оправданно, поскольку это будет у нас невизуальный ресурс. Соответственно, для него надо будет прописать маппинг в web.xml (на ControllerServlet) и в диспетчере воркеров (на LoginWorker.class).

В воркере надо прочитать параметры запроса login и password, пробить их через UserManager, и положить в VelocityContext объект типа User. ПДалее показать факт успешного логина (или ошибки) через вставной подшаблон confirmation.vm.

Пока этого будет достаточно.

Как его воткнуть грамотно вв шапку страницы, подумаю завтра. А так проверил работоспособность, работает.

template.vm

web.xml

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




У нас еще много будет невизуальных обработчиков всяких сабмитов, и все они будут проходить через тот же сервлет-контроллер, так что имеет смысл задать маппинг по расширению *.do.

С формой более-менее все в порядке, с обработчиком тоже. Так что перейдем к следующей задаче: запоминанию. Но сначала обещанный рефакторинг.

Речь идет о возвращаемом значении метода execute(). Он имеет тип VelocityContext. Это не совсем удобно, ибо это весьма общий тип. Коль скоро мы имеем дело с представлением вебной страницы, хорошо было бы, чтобы оно предоставляло нам прямой доступ к ряду существенных вебных штучек. Поэтому я предлагаю завести класс (назовем его Page), наследующий от VelocityContext, примерно такого содержания:



Соответственным образом изменится и сигнатура метода execute(). И вот что это нам сразу дает: мы сейчас легко и просто реализуем паттерн PRG (Post-Redirect-Get).

Пару слов о том, что это за паттерн и для чего он нужен. Если в ответ на сабмит формы возвращать отображаемый текст, то это чревато многими путаницами: например, если юзер решит походить кнопками браузера Взад/Вперед, или нажмет рефреш. Чтобы избежать этих неприятностей, есть достаточно простое решение: по сабмиту всегда возвращать HTTP код статуса 302 (ресурс временно перемещен), заодно в заголовке ответа Location указывается адрес для переадресации. В Servlet API для этой цели есть удобное сокращение: response.sendRedirect(String url);

Так вот, я предлагаю для всех обработчиков сабмитов выставлять переменную page.redirectUrl, а в коде сервлета ее анализировать и соответственно что-то делать. Возникает вопрос: а почему не вызывать sendRedirect() непосредственно в коде воркера? А потому, что в этом случае ответ сразу уйдет браузеру, а нам бы хотелось поманипулировать заголовками ответа, в том числе кукисами.

Итак, в LoginWorker пишем примерно так:



Вообще надо сказать, работа с куками в Servlet API сделана очень неудачно - приходится делать много лишних телодвижений для реализации самых простых вещей. Выходом может быть написание собственных удобных функций. Например, мы могли бы в Page предусмотреть очень простой метод setLongLivedCookie(String name, String value), и то, что мы тут делали в четыре строки, делалось бы в одну. Аналогичным образом можно было бы написать метод resetCookie(String name). Впрочем, все это со времени мы и сделаем.

Не забываем, что в сервлете-контроллере мы должны проверить значение переменной redirectUrl:



Теперь смотри, diablero: мы сейчас опять применим объектный подход и снова разом упростим структуру кода.

Юзера нам надо определять при каждом входящем запросе, потому что от этого зависит, что показывать, что не показывать, и показывать ли вообще. Чтобы не дублировать код чтения кукисов во всех воркерах, мы в базовом AbstractWorker можем написать такое:



Теперь, когда общая для всех воркеров часть работы закодирована, мы в производных классах пишем так:



Из предыдущего фрагмента особенно хорошо заметно, насколько убоги штатные средства работы с куками. Например, Cookie[] request.getCookies() еще нужно не забыть проверит на null, не говоря уж о выуживании кук по имени. Поэтому, diablero, будет хорошо, если ты реализуешь удобные методы работы с куками в классе Page.

После этого у тебя не должно возникнуть затруднений, чтобы сделать в шапке избирательное приветствие: либо "Привет, diablero! | Выход", либо "Имя: | Пароль: | Войти".


Это сообщение отредактировал(а) Stampede - 26.7.2007, 01:12

А как бы ты сделал?

Тем, кто, возможно, захочет пройти путем diablero:

• Коротенькая статейка по JPА, все что нужно, чтобы начать работу и набросать простую базу  (Entitiy, One-to-One, One-to-Many, Many-to-Many Relationships): Часть 1, Часть 2.
• Руководство по Apache'вскому OpenJPA,включает в себя обзор JPA стандарта, можно подсмотреть более тонкие вещи: OpenJPA users guide
• Пару слов про cookies в википедии. 
• Все, что нужно знать про Velocity: User's guide.

А ты угадай 




Maksym, спасибо за ссылки.

Это сообщение отредактировал(а) Stampede - 26.7.2007, 16:17

Думаю угадаю
Мне осталось с Cookie разобраться. Завтра доделаю, а сейчас арбайтен по стахановски

По поводу Cookies. Чтобы не писать лишнего, а сосредоточится на архитектуре, можно взять вот такой утилитный класс (спионерено отсюда):

Всетаки возникло. Я чего-то никак не доганю как выход сделать.


Во втором if'е надо плюшки сбросить и перегрузить главную страницу. Если даже сбросить вручную, то это ничего не дает. Потому, что при редиректе на home.shtml ничего не происходит.




Это сообщение отредактировал(а) diablero - 29.7.2007, 15:45