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

Материал из YourcmcWiki
Перейти к: навигация, поиск
(Алгоритм)
 
(не показано 7 промежуточных версий этого же участника)
Строка 1: Строка 1:
'''editgeneric''' — тривиальный модуль для построения интерфейсов редактирования, пропагандирующий, я надеюсь, правильно разделение всего процесса на стадии.
+
'''editgeneric''' — тривиальный модуль для построения интерфейсов редактирования, пропагандирующий, я надеюсь, правильное разделение всего процесса на стадии.
  
* Проверка доступа (check_access)
+
* Проверка доступа ('''check_access''')
* Извлечение и проверка данных из параметров запроса (check_data)
+
: Наиболее очевидная вещь: имеет ли право текущий пользователь редактировать то, что он хочет редактировать?
* Извлечение данных из базы данных приложения / откуда угодно (fetch)
+
* Извлечение и проверка данных из параметров запроса ('''check_data''')
* Объединение данных из базы и изменений, вытащенных check_data (merge)
+
: Проверка корректности ввода: например, не занят ли логин при регистрации, корректно ли введён e-mail адрес и т. п.
* Дополнение и вывод объединённых данных в шаблон (template)
+
* Извлечение данных из базы данных приложения / откуда угодно ('''fetch''')
* Выполнение изменений (save)
+
: А этого этапа может не существовать вообще в компонентах создания новых объектов (но не редактирования существующих).
 +
* Объединение данных из базы и изменений, вытащенных check_data ('''merge''')
 +
: Идея в том, что нужна возможность попасть на интерфейс редактирования какого-то объекта, но чтобы в форму уже были внесены некоторые изменения.
 +
* Дополнение и вывод объединённых данных в шаблон ('''template''')
 +
: Например, преобразование времени в человеко-читаемый формат и т. п.
 +
* Выполнение изменений ('''save''')
 +
: В простейшем случае выполнение SQL-запроса UPDATE к БД.
 +
: Но также здесь, например, можно реализовать универсальную модерацию — «запрос на правку» ($data) сериализуется, сохраняется в таблицу, потом модератор проверяет и принимает либо отклоняет.
 +
: Кстати, функция после отработки и сама может отдавать редирект куда-нибудь, например, на страницу с результатами редактирования. По умолчанию же, если save вернёт ИСТИНУ и не выведет ничего в \%rv, будет редирект на исходный URL редактирования.
  
 
Общий порядок параметров всех хуков: (\%param, \%rv, $data, $olddata). Все аргументы передаются хукам merge и template, первые 3 — хуку save, остальным только первые 2.
 
Общий порядок параметров всех хуков: (\%param, \%rv, $data, $olddata). Все аргументы передаются хукам merge и template, первые 3 — хуку save, остальным только первые 2.
Строка 14: Строка 22:
 
Порядок действий:
 
Порядок действий:
  
# Если умеем, проверить доступ (выполнить check_access, если функция существует)
+
# Если умеем, проверить доступ (выполнить '''check_access''', если функция существует). Если она вернёт ЛОЖЬ:
 
#: Если она что-то вывела в \%rv (данные шаблона), вернуть \%rv
 
#: Если она что-то вывела в \%rv (данные шаблона), вернуть \%rv
 
#: Иначе просто отдать статус HTTP ''403 Forbidden''
 
#: Иначе просто отдать статус HTTP ''403 Forbidden''
# Если умеем, выполнить check_data, и получить $data (вероятно хешреф)
+
# Если умеем, выполнить '''check_data''', и получить $data (вероятно хешреф)
# Если задан параметр <code>'''do'''</code>, перейти к выполнению действия:
+
# Если задан параметр '''do''', перейти к выполнению действия:
## Если функция check_data задана, но вернула ЛОЖЬ, вернуть ошибку
+
## Если функция '''check_data''' задана, но вернула ЛОЖЬ, вернуть ошибку
## Если функция save задана, выполнить её, если она вернёт ЛОЖЬ, вернуть ошибку
+
## Если функция '''save''' задана, выполнить её, если она вернёт ЛОЖЬ, вернуть ошибку
## Если функция save не задана или вернула ИСТИНУ, отдать перенаправление на URL edit_from_uri из параметров запроса (URL, по которому была форма редактирования)
+
## Если функция '''save''' не задана или вернула ИСТИНУ, отдать перенаправление на URL '''edit_from_uri''' из параметров запроса (URL, по которому была форма редактирования)
# Если умеем, выполнить fetch и получить от него $olddata
+
# Если умеем, выполнить '''fetch''' и получить от него $olddata
# Если умеем, выполнить merge и получить от него $data объединённый с $olddata
+
# Если умеем, выполнить '''merge''' и получить от него $data объединённый с $olddata
 
#: Если не умеем, просто дописать в хеш %$data значения из %$olddata, не заданные в %$data
 
#: Если не умеем, просто дописать в хеш %$data значения из %$olddata, не заданные в %$data
 
#:: Если $data — не хешреф, то не делать этого :-)
 
#:: Если $data — не хешреф, то не делать этого :-)
# Если умеем, выполнить template, он выведет $data и $olddata в \%rv
+
# Если умеем, выполнить '''template''', он выведет $data и $olddata в \%rv
 
#: Если не умеем, просто записать data в $rv по ключу data, а $olddata по ключу olddata.
 
#: Если не умеем, просто записать data в $rv по ключу data, а $olddata по ключу olddata.
  
 
[[Категория:Sway]]
 
[[Категория:Sway]]

Текущая версия на 00:05, 21 августа 2009

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

  • Проверка доступа (check_access)
Наиболее очевидная вещь: имеет ли право текущий пользователь редактировать то, что он хочет редактировать?
  • Извлечение и проверка данных из параметров запроса (check_data)
Проверка корректности ввода: например, не занят ли логин при регистрации, корректно ли введён e-mail адрес и т. п.
  • Извлечение данных из базы данных приложения / откуда угодно (fetch)
А этого этапа может не существовать вообще в компонентах создания новых объектов (но не редактирования существующих).
  • Объединение данных из базы и изменений, вытащенных check_data (merge)
Идея в том, что нужна возможность попасть на интерфейс редактирования какого-то объекта, но чтобы в форму уже были внесены некоторые изменения.
  • Дополнение и вывод объединённых данных в шаблон (template)
Например, преобразование времени в человеко-читаемый формат и т. п.
  • Выполнение изменений (save)
В простейшем случае выполнение SQL-запроса UPDATE к БД.
Но также здесь, например, можно реализовать универсальную модерацию — «запрос на правку» ($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.