Цитата(diablero @ 25.7.2007, 11:30  ) | | Классы по пакетам сгруппировал, может быть имя не совсем удачное выбрал? |
Ну, я бы точно по другому сделал. У тебя там бины данных, менеджеры и воркеры в одной куче оказались. Но дело твое.
| Цитата(diablero @ 25.7.2007, 14:17 ) |
<servlet-mapping>
<servlet-name>ControllerServlet</servlet-name>
<url-pattern>/submit/login.do</url-pattern>
</servlet-mapping>
|
У нас еще много будет невизуальных обработчиков всяких сабмитов, и все они будут проходить через тот же сервлет-контроллер, так что имеет смысл задать маппинг по расширению *.do.
С формой более-менее все в порядке, с обработчиком тоже. Так что перейдем к следующей задаче: запоминанию. Но сначала обещанный рефакторинг.
Речь идет о возвращаемом значении метода execute(). Он имеет тип VelocityContext. Это не совсем удобно, ибо это весьма общий тип. Коль скоро мы имеем дело с представлением вебной страницы, хорошо было бы, чтобы оно предоставляло нам прямой доступ к ряду существенных вебных штучек. Поэтому я предлагаю завести класс (назовем его Page), наследующий от VelocityContext, примерно такого содержания:
| Код |
public class Page extends VelocityContext {
private String redirectUrl;
public Page(HttpServletRequest request, HttpServletResponse response) {
put("request", request);
put("response", response);
put("url", request.getRequestURI());
}
// а также геттер и сеттер для redirectUrl
}
|
Соответственным образом изменится и сигнатура метода execute(). И вот что это нам сразу дает: мы сейчас легко и просто реализуем паттерн PRG (Post-Redirect-Get).
Пару слов о том, что это за паттерн и для чего он нужен. Если в ответ на сабмит формы возвращать отображаемый текст, то это чревато многими путаницами: например, если юзер решит походить кнопками браузера Взад/Вперед, или нажмет рефреш. Чтобы избежать этих неприятностей, есть достаточно простое решение: по сабмиту всегда возвращать HTTP код статуса 302 (ресурс временно перемещен), заодно в заголовке ответа Location указывается адрес для переадресации. В Servlet API для этой цели есть удобное сокращение: response.sendRedirect(String url);
Так вот, я предлагаю для всех обработчиков сабмитов выставлять переменную page.redirectUrl, а в коде сервлета ее анализировать и соответственно что-то делать. Возникает вопрос: а почему не вызывать sendRedirect() непосредственно в коде воркера? А потому, что в этом случае ответ сразу уйдет браузеру, а нам бы хотелось поманипулировать заголовками ответа, в том числе кукисами.
Итак, в LoginWorker пишем примерно так:
| Код |
protected Page page;
public Page execute(HttpServletRequest request, HttpServletResponse response) {
public static final AGE_NINETY_DAYS = 3600 * 24 * 90; // 90 days in seconds
page = new Page(request, response);
// ...
User user = userManager.login(userName, pasword);
if (user != null) {
page.put("user", user);
Cookie cookie = new Cookie("userName", user.getName());
cookie.setPath("/");
cookie.setMaxAge(AGE_NINETY_DAYS);
response.addCookie(cookie);
cookie = new Cookie("password", user.getPassword());
cookie.setPath("/");
cookie.setMaxAge(AGE_NINETY_DAYS);
response.addCookie(cookie);
page.setRedirectUrl("/confirmation.shtml");
} else {
// строка внизу закомментрована, поскольку она нам ничего не дает:
// после редиректа от нее ничего не останется. На самом деле
// такие вещи надо делать через сессию, но мы пока об этом не будем.
// page.put("message", "Invalid user name or pasword.");
// тут по-хорошему нужно на всякий случай сбросить кукисы userName и password
// на клиенте, но мы щас не будем загромождать код
page.setRedirectUrl("/login.shtml");
}
}
|
Вообще надо сказать, работа с куками в Servlet API сделана очень неудачно - приходится делать много лишних телодвижений для реализации самых простых вещей. Выходом может быть написание собственных удобных функций. Например, мы могли бы в Page предусмотреть очень простой метод setLongLivedCookie(String name, String value), и то, что мы тут делали в четыре строки, делалось бы в одну. Аналогичным образом можно было бы написать метод resetCookie(String name). Впрочем, все это со времени мы и сделаем.
Не забываем, что в сервлете-контроллере мы должны проверить значение переменной redirectUrl:
| Код |
public void service(...) throws ... {
// ...
Page page = worker.execute(request, response);
if (page.getRedirectUrl() != null) {
response.sendRedirect(page.getRedirectUrl());
} else {
Writer writer = response.getWriter();
// ...
}
}
|
Теперь смотри, diablero: мы сейчас опять применим объектный подход и снова разом упростим структуру кода.
Юзера нам надо определять при каждом входящем запросе, потому что от этого зависит, что показывать, что не показывать, и показывать ли вообще. Чтобы не дублировать код чтения кукисов во всех воркерах, мы в базовом AbstractWorker можем написать такое:
| Код |
public abstract class AbstractWorker implements Worker {
protected HttpServletRequest request;
protected HttpServletResponse response;
protected Page page;
protected User user;
// ...
public Page execute(HttpServletRequest request, HttpServletResponse response) {
this.request = request;
this.response = response;
page = new Page(request, response);
Cookie[] cookies = request.getCookies();
// тут мы каким-то образом получаем интересующие нас кукисы,
// и если все совпадает, присваиваем значение переменной user,
// которая будет видна в экземпляре производного воркера.
}
}
|
Теперь, когда общая для всех воркеров часть работы закодирована, мы в производных классах пишем так:
| Код |
@Override
public Page execute(HttpServletRequest request, HttpServletResponse response) {
super.execute(request, response);
// а тут уже делаем все специфическое для данного воркера
}
|
Из предыдущего фрагмента особенно хорошо заметно, насколько убоги штатные средства работы с куками. Например, Cookie[] request.getCookies() еще нужно не забыть проверит на null, не говоря уж о выуживании кук по имени. Поэтому, diablero, будет хорошо, если ты реализуешь удобные методы работы с куками в классе Page.
После этого у тебя не должно возникнуть затруднений, чтобы сделать в шапке избирательное приветствие: либо "Привет, diablero! | Выход", либо "Имя: | Пароль: | Войти".
|
по статусу(под аватарой) предположил? 
. Люди! Спасите сериал! Может batigoal всё же "поработает" учеником 
. Stampede, Вы не против?
и вопше то я тоже учитса хочу........
Оно у всех запускается без проблем? 
Да, на PHP поначалу проще, но когда проект разрастается... Где тут смайлик самоубийцы? И к тому же от от сервлетно-шаблонного подхода веет этаким... профессионализмом, что ли... программерским благородством... Не знаю даже, как описать.