Модуль editgeneric (Sway) — различия между версиями

Материал из YourcmcWiki
Перейти к: навигация, поиск
м
Строка 6: Строка 6:
 
: Проверка корректности ввода: например, не занят ли логин при регистрации, корректно ли введён e-mail адрес и т. п.
 
: Проверка корректности ввода: например, не занят ли логин при регистрации, корректно ли введён e-mail адрес и т. п.
 
* Извлечение данных из базы данных приложения / откуда угодно ('''fetch''')
 
* Извлечение данных из базы данных приложения / откуда угодно ('''fetch''')
: А этого этапа может не существовать вообще в компонентах создания новых объектов (но не редактирования сущестующих).
+
: А этого этапа может не существовать вообще в компонентах создания новых объектов (но не редактирования существующих).
 
* Объединение данных из базы и изменений, вытащенных check_data ('''merge''')
 
* Объединение данных из базы и изменений, вытащенных check_data ('''merge''')
 
: Идея в том, что нужна возможность попасть на интерфейс редактирования какого-то объекта, но чтобы в форму уже были внесены некоторые изменения.
 
: Идея в том, что нужна возможность попасть на интерфейс редактирования какого-то объекта, но чтобы в форму уже были внесены некоторые изменения.

Версия 00:03, 21 августа 2009

editgeneric — тривиальный модуль для построения интерфейсов редактирования, пропагандирующий, я надеюсь, правильное разделение всего процесса на стадии.

  • Проверка доступа (check_access)
Наиболее очевидная вещь: имеет ли право текущий пользователь редактировать то, что он хочет редактировать?
  • Извлечение и проверка данных из параметров запроса (check_data)
Проверка корректности ввода: например, не занят ли логин при регистрации, корректно ли введён e-mail адрес и т. п.
  • Извлечение данных из базы данных приложения / откуда угодно (fetch)
А этого этапа может не существовать вообще в компонентах создания новых объектов (но не редактирования существующих).
  • Объединение данных из базы и изменений, вытащенных check_data (merge)
Идея в том, что нужна возможность попасть на интерфейс редактирования какого-то объекта, но чтобы в форму уже были внесены некоторые изменения.
  • Дополнение и вывод объединённых данных в шаблон (template)
Например, преобразование времени в человеко-читаемый формат и т. п.
  • Выполнение изменений (save)
Например, выполнение запроса обновления к БД.
Здесь можно реализовать универсальную модерацию — «запрос на правку» ($data) сериализуется, сохраняется в таблицу, потом модератор проверяет и принимает либо отклоняет.
Кстати, функция после отработки и сама может отдавать редирект куда-нибудь, например, на страницу с результатами редактирования. По умолчанию же, если save вернёт ИСТИНУ и не выведет ничего в \%rv, будет редирект на исходный URL редактирования.

Общий порядок параметров всех хуков: (\%param, \%rv, $data, $olddata). Все аргументы передаются хукам merge и template, первые 3 — хуку save, остальным только первые 2.

Алгоритм

Порядок действий:

  1. Если умеем, проверить доступ (выполнить check_access, если функция существует)
    Если она что-то вывела в \%rv (данные шаблона), вернуть \%rv
    Иначе просто отдать статус HTTP 403 Forbidden
  2. Если умеем, выполнить check_data, и получить $data (вероятно хешреф)
  3. Если задан параметр do, перейти к выполнению действия:
    1. Если функция check_data задана, но вернула ЛОЖЬ, вернуть ошибку
    2. Если функция save задана, выполнить её, если она вернёт ЛОЖЬ, вернуть ошибку
    3. Если функция save не задана или вернула ИСТИНУ, отдать перенаправление на URL edit_from_uri из параметров запроса (URL, по которому была форма редактирования)
  4. Если умеем, выполнить fetch и получить от него $olddata
  5. Если умеем, выполнить merge и получить от него $data объединённый с $olddata
    Если не умеем, просто дописать в хеш %$data значения из %$olddata, не заданные в %$data
    Если $data — не хешреф, то не делать этого :-)
  6. Если умеем, выполнить template, он выведет $data и $olddata в \%rv
    Если не умеем, просто записать data в $rv по ключу data, а $olddata по ключу olddata.