Как правильно организовать админ-интерфейс

[varan]

Как правильно организовать админ-интерфейс

Как правильно организовать обработку сообщений при администрировании сайта? Все, что я пробовал до этого мне не нравится.
например, есть какая-то страничка в админ-интерфейсе на которой есть какая-то форма с hidden-полем action
На этой страничке есть подразделы, у которых есть свои подразделы и т.д., и у каждой есть, допустим, какой-то action (например 'save_html' и параметры)

проблема и в том кому обрабатывать POST и какую страницу показывать в зависимости от GET

как лучше сделать:
1) Один класс с большим оператором switch, который в зависимости от action вызывает нужный класс с нужными параметрами
2) класс главного раздела админ-интерфейса, который знает в зависимости от пришедших параметров какой класс инициализировать, тот в свою очередь знает что ему инициализировать и т.д.
3) Передавать в поле action название класса и метода
4) Что-то еще?

Сорри, если непонятно объяснил, если что - спрашивайте, уточню

 

[AlexVN]

1) Тогда этот класс (контроллер) становится очень большим "узким местом".
2) Можно и так.
3) И так можно.
Вообще можно, как тебе лично удобнее и что ты считаешь правильным. Сделать унеиверсальное решение не получится - всегда может всплыть такое требование, которое приведет к тому, что надо все переписывать. И если у тебя хорошая фантазия, то ты никогда не закончишь работу. Это лирика.
А практика - читай MVC паттерн и собственно C - controller.

 

[Константин_WEB]

1)2) Чем отличаются?
3) очень сомнительный, т.к. ты завязываешся на реализацию (имена методов и классов).

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

Тем более, ты сам написал, что

На этой страничке есть подразделы, у которых есть свои подразделы и т.д., и у каждой есть, допустим, какой-то action (например 'save_html' и параметры)

а это и есть иерархия (2 способ)

 

[Said]

не советую называть это хидден поле action - может конфликтнуть со свойством form.action

 

[varan]

В javascript?
Мне по барабану. Ну хорошо, буду называть what

 

[Константин_WEB]

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

Кстати, на каком пункте остановился и почему?

 

[varan]

Думаю, надо брать вариант 2, а еще лучше 4

В варианте 2 будет ужасное количество скрытых полей в формах и ужасно длинный урл. Типа такого:

main_action=view_frame&frame=1&frame_action=view_properties&selected_propertie=5&propertie_action=view_form

И получается, каждый класс должен помнить всю иерархию, чтобы создать такой урл. Либо она должна передаваться при инициализации. Что-то не нравится мне все это.

 

[AlexVN]

Да... Не прикольно.
Кстати, кстати, если бы больше знать о описании задачи, то дискуссия была бы более конкретной.

 

[varan]

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

 

[AlexVN]

Ок. Может попробуем тогда плясать от "Как правильно организовать обработку сообщений при администрировании сайта?" - что такое обработка сообщений? Выбор действия на основе параметров из request?
Чем админинистрирование сайта отличается от работы с ним пользователей?
Используется одна форма на страницу?
Почему нельзя для каждого раздела сделать собственную форму? Если в этом и есть конструкторская мысль, почему бы проставить всем кнопкам на странице уникальные имена и сделать один загрузчик на модель в начале обработки страницы и затем вызывать соответствующий обработчик по имени кнопки?

 

[varan]

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

 

[Powerhead13]

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

У меня все входящие данные обрабатываются отдельным классом, там их и можно как-то компоновать. Кроме того, можно вставить фильтры принимаемых данных в самих конечных классах и передавать им всё что есть.. я так и попробую сделать

 

[varan]

Зато потом, если ты захочешь изменить структуру классов, или просто что-то переименовать, это будет довольно проблематично.

 

[Powerhead13]

varan так же проблематично, как и редактировать класс-контроллер. По-моему написание этого класса более громоздко, чем 3-й вариант.