Немного переделал и перезалил. Пока шаблоны будут в таком стиле.

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

Еще несколько вопросов:
1. ты уже говорил о вариантах передачи css и прочих ресурсов, так как мы будем делать?
2. знаешь ли ты бесплатный хостинг, чтобы туда влез наш проект?
3. какой ты можешь порекомендовать из платных?


Это сообщение отредактировал(а) diablero - 7.8.2007, 01:17

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

Это сообщение отредактировал(а) diablero - 8.8.2007, 19:26

Присоединённый файл ( Кол-во скачиваний: 41 )
 templates.zip 4,06 Kb

Посмотрел форму регистрации. Замечания:

• Черный текст на болотном фоне почти не видно.
• Имя инпута для Пароль и Повторите пароль одинаковое, password.
• Значение value для Пол одинаковое, male.
• Календарь просто выкинь нах! Тем более такое страшный и глючный. И вообще, с точки зрения юзабилити вводить дату рождения через такой календарь крайне неудобно. Сделай лучше обычным текстовым полем и предлоим маску ввода дд/мм/гггг.
  
  И вообще по поводу Javascript: давай пока не будем его трогать. Штука мощная, но надо пользоваться ею с умом. А от ламерских скриптов вообще держаться подальше 
• Для подписей к радиокнопкам используй тэг <label for="radiobitton-id">Мужской</label>. Тогда подписи будут тыкабельными.

По вопросам:



Первый вопрос имеется в виду, как выдавать статику? Да обычно, дефолтным сервлетом. Просто ты сгоряча прописал у себя в web xml маппинг "/" на ControllerServlet, а надо бы ло только по расширениям '.shtml и *.do. Как только исправишь, Томкат начнет выдавать картинки и прочую статику.

Бесплатных хостингов не знаю. Сам использую платный 4java.ca.

Завтра начнем делать обработчик форм.

Так, ладно, давай делать обработчик форм.

Снечала предварительные замечания. Если бы мы делали мощное веб приложение с развернутой функциональностью, мы бы наваяли соответствующий фреймворк, обеспечивающий автоматическую валидацию: через рефлексию, по аннотациям, возможно с применением Javascript, и прочими штучками. Но поскольку форм у нас будет мало - пальцев одной руки хватит, чтоб посчитать - то мы всем этим заморачиваться не будем. Просто для каждой формы будет свой обработчик по типу LoginWorker, в котором и будет зашита логика валидации.

Итак, форма регистрации. Я предлагаю сделать ее с прицелом на то, чтобы впоследствии ее же можно было использовать для редактирования профиля. Но все по порядку. Примем такую схему:

УРЛ: /form/registration.shtml
Воркер: RegistrationFormWorker
Шаблон: forms/profile.vm

    | (по сабмиту)
    V

УРЛ: /submit/register.do
Воркер: RegisterWorker    --> (если ошибка, то возврат на стр. формы)

    | (если все ОК, редирект на стр. подтверждения)
    V

УРЛ: /confirmation.shtml
Воркер: ConfirmationWorker
Шаблон: confirmation.vm

RegistrationFormWorker пока будет без логики (только положи в контекст $content = "forms/profile.vm").

В RegisterWorker проверь, чтобы все обязательные поля были на месте, чтобы пароль в обоих полях был одинаковым, и чтобы юзера с таким именем в базе не было. Если что-то из этого не выполняется, футболь обратно: page.setRedirectionUrl("/form/registration.shtml").

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

Если есть вопросы - не стесняйся.

Сделал, работает до того момента, как заливать юзера в базу.



Думается плохо, продолжаю разбираться

diablero, Stampede, один момент. В коде класса TemplateManager метод mergeTemplate из класса org.apache.velocity.app.VelocityContext вызывается таким способом:

Этот метод deprecated, и несмотря на то, что он хорошо работает под Tomcat, Jetty отчаянно рушил мне все русские слова в шаблонах, что стоило немалой головной боли. Заранее неизвестно, где выплывут новые грабли, поэтому рекомендую заменить его на более современный вариант:

То есть:

Shaggie посмотрел доки к пакету, и не увидел что метод этот deprecated.
Посмотри исходники, и с кодировками все прозрачно будет

Вылетает тут:

Пока никак не могу понять, по отдельности работает...

Дак ты же пытаешься заново начать транзакцию. Ты к этому моменту уже в транзакции! Так что просто убери все что у тебя там относится к транзакции, включая commit()  и rollback(), и все будет пучком. Обо всех этих вещах уже "позабочено" в методе service().

Я это понял, и чтобы загладить свою глупость хотел пост подредактировать. А ты уже ответил

Не надо этого делать. На заглаженной глупости может поскользнуться кто-то другой 

Что мы сейчас имеем.
1. проеверяем что пользователя такого нет.
2. что пароли совпадают, но не проверяем сложность.

Сразу вскрылась недоработка, нам нужно создать бин group.
Я еще не нашел как прикрутить шаблон ввода к дате.

Что делаем дальше? До конца прорабатываем форму?

Нет, не надо.

Сейчас мы добавим в нашу картину вселенной вебсайта один полезный элемент. Суть вот в чем. Когда юзер ошибается во вводе данных, мы должны перенаправить его обратно на страницу формы. Но на ней уже должны быть заполнены те поля, которые он ввел ранее, плюс каким-то образом обозначено, в чем заключалась ошибка. Возникает вопрос: как это сделать?

Прежде чем предложить решение, я хотел бы напомнить, что все, абсолютно все формные данные приезжают к нам на сервер в виде текста, а если точнее, то в виде пар parameter=value. Для удобства работы с этими парами в Servlet API есть метод request.getParameter(String name) и другие. Отсюда напрашивается решение: если мы каким-то образом сохраним эти значения между обращениями к /form.registration.shtml, то сможем при рисовании формы заполнять поля теми значениями, которые поступили по сабмиту!

Вопрос: где сохранять эти данные? Дак, вестимо, в сессии!

Остается еще один вопрос: а в каком виде это делать?

Вот тут мы и подходим к тому решению, которое я хотел предложить. Мы заведем достаточно простенький класс - назовем его FormData - унаследованный для удобства от HashMap. Можно, конечно, организовать связь с мапом и через containment, но это потребует больше писанины. Класс примерно такой:



В принципе можно было бы вообще брать request.getParameterMap() и сохранять все мапом, но имея специализированный класс, мы сможем впоследствии добавлять всякие удобные штучки. Например, как видно из данного примера, мы можем сразу же добавить в обработчик такой код:



Теперь о том, как этим классом пользоваться. Во-первых, у нас изменится код RegistrationFormWorker. Если раньше мы просто клали в контекст имя шаблона, forms/registration.vm, то теперь работы будет побольше.

Чтобы сделать код шаблона проще, мы будем всегда передавать ему данные через объект FormData (например, в переменной контекста $formData). А объект этот сначала искать в атрибутах сессии, а если отсутствует - то создавать новый.

Замечу, что при регистрации этот новый объект FormData так и будет передаваться пустым, а вот когда мы ту же самую форму задействуем для редактирования профиля юзера, то мы этот новый экземпляр FormData сначала заполним значениями из объекта User.

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

Если передавать в класс  FormData request.getParameterMap(), то выскакивает такое исключение. 
Как я понял, возникает когда нет значение у ключа.

Поэтому сделал следующим образом:



Соответсвующим образом изменю LoginWorker'ы

Два замечания. Первое: ты преждевременно заводишь и инициализируешь объект FormData. Если регистрация проходит успешно, то он нам и не понадобится вовсе. Это раз.

Второе: трюки с перебором параметров неоправданно загромождают код воркеров, тем более что это дело можно запросто инкапсулировать. Так что все-таки используй конструктор new FormData(request.getParameterMap()), а уж в конструкторе делай всякие переборы с проверками.

Далее, вот здесь:



добавь все-таки еще одну строчку:



Это обезопасит тебя от ошибок в шаблоне.

И еще парочка предложений для реализации.

1. Текст сообщений об ошибке

Сейчас мы вынужденно пишем это сообщение по-английски. А нам бы надо по нашенски. Можно, конечно, сделать по i18n-ному, через ResourceBundle  и пр. Но можно и по простому. Например, передавать в качестве мессаджа не текст сообщения, а некую текстовую константу, скажем, "DUPLICATE_NAME" или "PASSWORD_MISMATCH", а в теле шаблона анализировать и выводить соответствующую фразу по-русски.

2. Текст подтверждения

Теперь ты уже можешь представить, как сделать так, чтобы на странице подтверждения выводился текст, зависящий от выполненного действия. Подсказка: нужно в сессию положить некий объект, в котором будет содержаться информация о типе действия и адрес линка для перехода.

Предлагаю класс для этой инфы разработать самостоятельно.