Прошу помощи в написании формы записи на приём

[Dimka]

Sla, ну правильно - модель, статика. Только я не понимаю, почему сразу база данных? Модель - это сущности и связи, они сперва описываются в коде функциями, переменными, классами. И сперва забиваются "рыбой". И только потом подключается база данных. Заодно готовая модель уже помогает спроектировать структуру базы данных.

Т.е. в первую очередь нужен контроллер и интерфейс модели для работы как контроллера, так и представления (view).

[Sla]

Так... кто сказал про базу?
Модель хранилища... да, а про базу ни-ни...

А "живые данные, не статика, требуются...
Существует расписание приема.
Сейчас это статика.

А реально?
Вот и нужны реальные данные - т.е хранилище.
В данном случае есть альтернатива хранилищу как не sql-база?

[Dimka]

Sla, если "про базу ни-ни", причём тут вчера ночью обсуждавшиеся таблицы? Да ещё и выявление ключей?

До реальных данных ещё форму нужно отладить. Это и есть вопрос постановки последовательных целей к достижению результата.

Логика работы формы вообще не обсуждалась: что и как там должно быть, как пользователь с ней будет работать. Какие элементы управления (control) на ней должны располагаться, какие между ними есть зависимости.

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

Это называется user story, которая разлагается на use cases, и каждый из них приводит к построению компонента, сквозного по отношению к клиенту, серверу и базе данных. И только когда все компоненты описаны, можно будет сказать, какая там модель данных, какие таблицы, какие ключи.

Так что в начале я предлагаю Kaspiy русским языком описать фантазию "Вот захожу я на страницу..." - что я там вижу (точный перечень), что и как я с этим могу/хочу делать, какой результат ожидаю увидеть у себя на экране. Можно кривой картинкой, нарисованной карандашом или в Paint - как удобнее. Тот HTML, что был на прошлой странице, не вполне соответствует заданию - там как минимум не хватает полей.

Затем из этой фантазии мы выбираем один элемент, и делаем его сквозное проектирование по всем элементам клиента и сервера, чтобы он работал, как задумывалось. Допусти, то же ФИО. Потом следующий. Если надо, добавляя взаимозависимости. И так до конца.

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

Для того, чтобы сделать эту минимальную итерацию, нужно сначала избавиться от всего, к делу не относящегося.

[Kaspiy]

Прошу меня простить за долгое отсутствие. Переезд занял много времени)И большое Вам спасибо за то,что уделяете так много внимания этой теме.
Dimka, вы сказали описать, как я вижу будущую форму записи на приём. Вот:
Обычный среднестатистический сайт. В меню страница "Записаться на приём", при переходе на которую пользователь видит возможные варианты причин приёма, например: заключения контракта, собеседование, приём заказа, деловые переговоры. После выбора одной из этих причин, пользователь переходит к другому окну, в котором выбирает более конкретную причину, тоесть: Собеседование -> Прием на работу, практика, стажировка. Дальше следует окно, в котором расположен календарь. Пользователь выбирает дату и по щелчку получает информацию о ВСЕХ часах приёма в этот день. Поля, в которых находятся часы,которые уже кем-то заняты - выделены красным. Пользователь выбирает свободное время, а в следующем окне указывает, является ли пользователь представителем физического, юридического лица, вводит свои ФИО, контактный номер,e-mail. Далее подтверждает,что все введенные данные верны и что он согласен со всеми условиями. Дальше пользователь жмет на кнопку:"Записаться на приём". Дальше пользователь видит сообщение, в котором говорится, что человек зарегистрировался и еще раз указывается время, число и место, где будет проходить приём.Это же сообщение дублируется в письме, которое получает пользователь на свой e-mail.
Вот, как я это вижу.

Добавлено через 40 минут и 9 секунд:
И еще, как оказалось,надо сделать так,чтобы сообщение о регистрации приходило СМС-кой на указанный телефон.

[Dimka]

Kaspiy, т.е. это то, что называется мастер (wizard). Чем обусловлен выбор именно этого формата? Тем, что форма должна быть маленькой для телефона? Тем, что "так задано"? Или просто так? Дело в том, что приведённое дробление информации для мастера избыточно с точки зрения удобства использования (usability): пользователю нужно делать дополнительные телодвижения для перехода туда-сюда между окнами, вместо того, чтобы всё сделать в одном окне. При том, что количество полей не настолько велико и запутано между собою хитрыми связями, чтобы непременно требовалось много окон.

видит возможные варианты причин приёма, например: заключения контракта, собеседование, приём заказа, деловые переговоры.

Это полный перечень? Или это только "например"? Возможно ли заранее получить полный перечень? Будет ли мастер как-то расширяться в этой части в будущем?

Собеседование -> Прием на работу, практика, стажировка.

Опять же: это полный перечень? Эта детализация есть для каждого предыдущего пункта, или для некоторых её нет?

является ли пользователь представителем физического, юридического лица, вводит свои ФИО, контактный номер,e-mail.

Юрлицо не нуждается в дополнительных полях: хотя бы название?

Если многостраничный мастер, то наверно в каждом следующем окне нужно ещё показывать, что навводил пользователь в предыдущем: невежливо заставлять человека напрягать память о том, какое число и время он выбрал в момент подтверждения? Или всё это должно быть только на странице подтверждения? А если пользователь передумал, ему надо листать страницы назад?

Поля, в которых находятся часы,которые уже кем-то заняты - выделены красным.

Обычно такое выделяют, наоборот, серым - недоступно. Или зачёркнутым, как ты предлагал изначально. А самое лучшее - вовсе не показывать, чтобы у пользователя лишний раз глаза не разбегались. Только перечень свободных часов или надпись "В этот день свободных часов нет".

Про SMS, сразу скажу, я не знаю - не отправлял. Но Sla, наверно, знает. Это явно надо либо какой-то сервис подключать, либо телефон. Тут я сам с интересом послушаю.

Итак, сейчас важно: уточнить то, о чём я спросил выше, и с учётом мною сказанного принять окончательное решение насчёт мастера и количества его окон.

[zubr]

По поводу SMS. У многих мобильных операторов есть возможность с сайта послать sms. Варианты решения:
1. Используя аякс передаем из своей формы запрос на отправку sms на сервер мобильного оператора.
2. Используя библиотеку curl php отправляем запрос серверу мобильного оператора со своего сервера.

[Kaspiy]

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

Добавлено через 16 секунд:
http://nottech.ru/online-booking

[Dimka]

Kaspiy, в таком случае набросай внеший вид формы (хоть картинкой, хоть сразу в HTML). Особо обрати внимание на поля выбора и клендарь.

Простой способ - это, конечно, combobox (выпадающий список). Как примерно ты на предыдущей странице показывал. Но с точки зрения удобства пользователя, порой бывают выгодны radiobuttons (круглые метки для выбора одного из вариантов). Что касается календаря и выбора времени, опять же, удобнее тыкнуть в определённое место таблицы.

Сейчас не обращай внимание на то, что ты знаешь/не знаешь. Сосредоточься на наиболее удобной для пользователя организации экрана с полями. Если из-за незнания не можешь показать свою мысль в HTML, нарисуй картинку. Если всё же не придумаешь ничего лучше предыдущего, то скажи об этом - будем разбирать ранее приведённый здесь HTML.

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

[Kaspiy]

Тоесть,лучше убрать календарь и добавить таблицу приёмных дней/часов? Как Вы думаете, как вообще лучше реализовать выбор даты/времени?
Рисунок, в целом, есть, вопрос только в этом.

[Dimka]

Kaspiy, думаешь ты, я только предлагаю варианты. Календарь видел в каком-нибудь органайзере? Там показывается вся карта дней месяца и можно листать по месяцам и годам вперёд-назад. Равно как и задачи размещать на шкале времени - обычно по 1 строчке на каждые полчаса.

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

[Kaspiy]

Вот,на скорую руку сварганил) Будем опираться на нотариальную тематику.

И после нажатия на "Записаться" пользователь получает сообщение о том,что он удачно зарегистрировался, там же показывается вся введенная информация, еще раз указывается время приёма и место,где он будет проходить. Такое же сообщение приходит на телефон и e-mail.

Добавлено через 2 минуты и 22 секунды:
Не загрузилась с первого раза =/

[Dimka]

Верхняя шапка сайта - это к странице отношения не имеет. Это отдельная история. Единственно, что если в шапке будет явно видно, что это "запись на приём", то на самой странице повторять не надо. Если же шапка будет какой-то другой, то начать страницу нужно с заголовка "Запись на приём".

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

Второй ряд - нелогичный. Тогда надо вторым действием сделать выбор физ-/юр- лица. И после уточнения этой информации третьим появится более сжатый список вариантов.

Также нужно более тщательно подумать над словами. Потому что в двух списках используется слово "действия" - нет разницы. Если её на самом деле нет, возможно, верхние панели выбора вовсе лишние.

Тогда на первое выходит рубрика "Кто вы?" - варианты: физик, юрик, ИП.

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

Дальше рубрика "Какое время вам удобнее?", где календарь с часами. Всплывать лучше ничему не надо. Лучше обновлять список часов при выборе даты. И всё же, если это список "Свободных часов", что в нём делают уже занятые часы?

Работа с календарём тоже требует логики и динамики.

Во-первых, нельзя выбирать даты в прошлом.

Во-вторых, нельзя слишком забегать в будущее. Или можно?

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

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

Следующая рубрика "Представьтесь, пожалуйста" с соответствующими полями.

Последние галочки... ну понятно, конечно, но вот лично меня это раздражает везде, где встречается. Это не надо делать галочками, это просто надпись. Потому что нажатие кнопки невозможно без этих галочек, а нажатие кнопки означает, что условия приняты. Поэтому вместо "Настоящим подтверждаю..." (к тому же это не цифровая подпись юзера в этом месте), возможно, стоит сделать "Записываясь на приём через сайт, вы автоматически даёте согласие на..." ну или что-нибудь более гладкое. Тем более, что упомянутый там список документов на форме нигде не представлен. Видимо, надо сделать ссылку, открывающую новое окно на этот список?

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

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

Затем начнём делать форму с конца: сперва кнопка, потом ФИО и т.п. (начерно), потом календарь с временем (самое сложное), в самом конце всякие верхние выборы. Дойдя до верха пойдём вниз, подправляя нестыковки. И форма будет готова.

P.S. Судя по эскизу, стиль Web 2.0. Напрашивается реализация через AJAX. Что ж, будем JavaScript разбирать. Не настолько он и сложный по сравнению с PHP.

[Sla]

По поводу СМС информирования.
Существует масса сервисов, так называемых шлюзов.
Каждый шлюз имеет свой API. Кто-то работает через SOAP, кто-то на "чистом" curl. Принцип один: зарегистрированный аккаунт с действующим балансом отсылает регистрационные данные, текст и номер - в ответ получает ok или error с детализацией о балансе, и прочей инфы. Но пока это рано... И даже внесение в функционал на данном этапе не нужно рассматривать, можно только заняться поиском и выбором шлюза.

http://slasoft.kharkov.ua/test/zapis.html
Вот простейшая форма записи...
Не вижу необходимости, даже добавлять другие поля, такие как причина записи.
Достаточно, на данном этапе научиться заполнять расписание.

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

Сначала. Заполнить  расписание (дата + время) остальное потом.

ШАГ 1.

Подготовка данных сервер:

Выводим поле Имя (пустое)
Заполняем поле валидной доступной даты
Рендеринг и вывод подготовленных данных


Действия пользователя:
Ввод имени
Выбор даты
-- посылка данных для получения доступного времени приема ->

ШАГ 2

Подготовка данных сервер:

Выводим поле Имя (анализ валидности имени (например,  пустое - выводим предупреждение об ошибке)
Заполняем поле валидной доступной даты (анализ даты на валидность - правильность заполнения и существования даты в расписании, в случае ошибки - предупреждение)
При ошибке даты выводим (рендеринг)
При отсутствии ошибки заполняем поле времени приема, исходя из незанятости


Действия пользователя
Выбор даты приема
Отправка данных на сервер

Дальше я предлагаю продолжить Kaspiy - расписать действия серверной части
 




Имя -> Выбор даты -- поиск

[Kaspiy]

Сменил расположение элементов, текст подредактировал.

1 пункт - кнопки: хочу оставить их, как панели с подсвечиванием (на рисунке видно). Далее выпадает список, относящийся к данной категории.

2 пункт - часы и календарь: Ваш вариант - отличное решение))Так и сделаем (на рисунке есть тоже). Запись вперед максимум на 3 месяца.

3 пункт - если нотариус заболел: давайте в таком случае предложим пройти регистрацию заново. Я думаю, не стоит создавать личный кабинет  для пользователей (но он нужен будет для нотариусов). И да, если в то время, как один пользователь копается в форме, другой уже занял это время, надо выводить соответствующее сообщение.

4 пункт - ссылка на документы. (выделил на рисунке). Тут Вы,опять же, правы. Следует дать ссылку на перечень документов.

Я благодарен Вам за отличные решения.

Sla,
простите, но я не очень понял, что вы хотите чтобы я написал. Вы ведь описали шаги ОТ и ДО отправки данных на сервер. Что же еще?

[Sla]

но я не очень понял, что вы хотите чтобы я написал.

Я хочу чтоб ты описал действия серверной части после получения всех данных.


Как я вижу... Мы уходим от цели, развивая форму ввода...
Считаю, что этого не надо.
Поле имя - это по сути набор полей идентифицирующие пользователя (заявителя).

Основная задача - расписание - оно является основоопределяющим, документы, выбор нотариусов - это позже... .

менил расположение элементов, текст подредактировал.

1 пункт - кнопки: хочу оставить их, как панели с подсвечиванием (на рисунке видно). Далее выпадает список, относящийся к данной категории.
Да, пожалуйста... Только расскажи как ты будешь хранить


2 пункт - часы и календарь: Ваш вариант - отличное решение))Так и сделаем (на рисунке есть тоже). Запись вперед максимум на 3 месяца.
Сейчас лишнее - 3 месяца большой срок


3 пункт - если нотариус заболел: давайте в таком случае предложим пройти регистрацию заново. Я думаю, не стоит создавать личный кабинет  для пользователей (но он нужен будет для нотариусов).

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

4 пункт - ссылка на документы. (выделил на рисунке). Тут Вы,опять же, правы. Следует дать ссылку на перечень документов

[Kaspiy]

Ну...если бы категории проходили как <option> в $kategorii, то дальше я бы использовал if , else if, как делал в калькуляторе, а уточняющий(выпадающий список) выводился бы с помощью echo.

[Sla]

Ну...если бы категории проходили как <option> в $kategorii, то дальше я бы использовал if , else if, как делал в калькуляторе, а уточняющий(выпадающий список) выводился бы с помощью echo.

О чем речь?

[Sla]

На моей тестовой странице есть блок имитирующий выбор документов.

[Kaspiy]

После получения всех данных в БД создается запись с уникальным ID, который присвоен конкретному пользователю. В этой записи находится вся информация, которую юзер указал при регистрации. Связка день+время, которая уже есть в какой-то записи, удаляется из возможных часов приёма.
Оно?

[Sla]

ОНО?

Оно

Аргументируй

Связка день+время, которая уже есть в какой-то записи, удаляется из возможных часов приёма.

А какие еще возможны способы?

Напоминаю, что часы приема, режим работы - административные функции (на них, в данном случае невозможно повлиять из пользовательского интерфейса  - DML кроме update запрещены)

[Kaspiy]

Подождите, мы берем вариант развития событий,где занятое время удаляется из списка возможных часов или выделяется красным?
Если 1 вариант, то, конечно, эта связка не должна присутствовать при регистрации другим пользователем на это же время. Тоесть, если один человек выбрал
12 декабря 12:00,то для другого человека уже не является возможным в тот же день выбрать 12:00.

[Sla]

Подождите, мы берем вариант развития событий,где занятое время удаляется из списка возможных часов или выделяется красным?
Если 1 вариант, то, конечно, эта связка не должна присутствовать при регистрации другим пользователем на это же время. Тоесть, если один человек выбрал
12 декабря 12:00,то для другого человека уже не является возможным в тот же день выбрать 12:00.

Не существенно...
Оно может не показываться, или показываться красным - это несущественно.

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

[Sla]

Не старайся охватить необъятное... и предусмотреть все возможные и невозможные ситуации. По крайней мере, на этом этапе.

[Kaspiy]

Не существенно...
Оно может не показываться, или показываться красным - это несущественно.

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

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

[Sla]

Не "выкручивайся" - зациклился на своем решении

Расписание
День     Дата    Статус
01/01    09:00      0
.....


После записи

День     Дата    Статус
01/01    09:00      1
.....

Откуда и что удалилось?

[Kaspiy]

тааак. В Вашем примере связке дата+время присваивается статус. Тоесть, 0 - когда оно свободно, и 1-когда занято. Выходит,нужно сделать так,чтобы следующий пользователь при регистрации видел только связки со статусом 0.

[Sla]

Напоминаю, что часы приема, режим работы - административные функции (на них, в данном случае невозможно повлиять из пользовательского интерфейса  - DML кроме update запрещены)

Исходя из этого

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

Ознакомься что такое DML, а также  DDL, DCL, TCL - если не сейчас, то на на будущее пригодится.

[Kaspiy]

Ознакомился. Почему я сразу не обратил на незнакомое слово внимание - воспользовался логикой) После ознакомления с официальной информацией понял, что логика не подвела)
выйдет что-то типа:

Код:

UPDATE [top(1)] <datetime> 
SET <[status1]> 
[WHERE <time is free>];
  

и/или

Код:

UPDATE [top(1)] <datetime> 
SET <[status0]> 
[WHERE <time is't free>];

[Sla]

Не совсем понял твою запись


UPDATE <TIME_RECEPTION> SET status = 'новый статус'
WHERE <TIME_CHOICE>

[Kaspiy]

но тогда надо сменить "SET status = 'новый статус'" на "SET status = '1'", верно? Мы же будем работать с Статусом 1 и Статусом 0.