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

Обычно, админка состоит из комплекта функциональных страниц с информацией. На каждой такой странице расположена форма, которая что-то такое умное делает.

Итого, нужно иметь класс admin, в котором некоторые методы названы характерным образом,напрмер menu_XXX
К примеру, наша админка содержит список роликов youtube и что=то с ними делает.



в админке заводим reflection от этого класса и пробегая по списку функций и выбирая из них menu_*** - получаем список для меню админки. При некоторой ловкости рук  - можно формировать многоуровневые меню в стиле `menu_xxx_yyy`

Для каждого метода доступен phpDoc комментарий функцией getDocComment(); Первая строчка комментария вполне себе тянет на строчку меню.

Если юзер выбрал этот пункт меню , можно сформировать форму, используя параметры getParameters() (теги @param)? которые построчно можно анализировать регуляркой, при этом посматривая на комментарий. Первая часть имени - "тип" идентификатора. Если его нет - параметр считается обычным текстовым типом. Недостающие параметры для отображения можно нарыть, поковыряв дополнительные строки комментария...

Для этого примера при выборе пункта `Редактор роликов` будет выведен список роликов (с радиобатонами, например, в качестве поля формы). Для пункта `Изменить ролик на главной` будет форма из 2-х полей: текстовое поле и тот же список роликов. и так далее.

При POST'е формы, наконец то приходит пора для вызова конкретно этой функции класса с уже полученными и проверенными параметрами.

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

Кто нибудь видел такие конструкторы? Или, может, какие мысли появились?

мысль интересна, надо пробовать его развивать в нужном направлении

Ух ты, меньше минуты от поста до реакции на него   

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

Это называется метапрограммированием. 
Меня тоже часто посещают мысли о унификации, универсализации, ретроспекции и прочих прелестях, которые бы могли заставить программу чуть ли не "думать самостоятельно" и сделать определение некоторых ее аспектов совершенно однозначным, а все остальное — динамическими последствиями... 
Только не во всех случаях это целесообразно, ибо долго, сложно, трудоемко. А тех, кому ты пишешь коды, не интересует насколько там все внутри будет прекрасно, элегантно и божественно... им лишь бы работало...

Это сообщение отредактировал(а) Arantir - 27.7.2013, 05:46

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

Попробую порассуждать вслух о том, как решить мою конкретную задачку.

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

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

От админки на первых порах будет хотеться таких возможностей:

•  просмотр информации по всем роликам, с фильтрацией по всем, определенным на сайте критериям (бренды, группы, производители)
•  выбор одного из списка роликов и установка его для показа на главной странице сайта
•  редактирование списка "вебинары", с сортировкой и переименованием - некий список роликов, простое перечисление.
•  демонстрация формы логина для неавторизованного юзера. Авторизация.
•  вывод параметров сайта, в частности, со сменой имени-пароля администратора сайта.

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

Так что появляется новый тег в phpDoc  @template, который нужно ожидать встретить в комментарии.

Для выбора одного ролика из списка, нам потребуется один элемент управления, со страничным выводом, фильтрами. Будем считать, что такой элемент соответствует типу video и представляет собой строку YID - идентификатор ролика на youtube. 

Для выбора списка роликов нужен дополнительный элемент, состоящий из предыдущего, для добавления новых элементов, и списка роликов с сортировкой. У него будет тип videolist, он будет представлять собой массив из YID'ов.

Отдельный тип param - параметры сайта. Он будет массивом с неопределенным количеством параметров, чтобы не приходилось перечислять их все поименно.

Остальные контролы - достаточно очевидные обычные html элементы

Итого - скелет класса admin будет примерно таким. Местами, практически, уже и не скелет 

Данная мыль хоть и интересна, однако не нова, в том или ином виде ее пытались реализовать в разных программных продуктах.


Я приведу несколько другой пример универсализации разработки. Пусть у нас админка строиться на основание данных. Данными может выступать как таблица в БД, так и модель в виде класса, так и некий файл описания связей в текстовом формате. 

То есть есть некий класса назовем его например AdminController пусть он работает с данными через интерфейсом(на самом деле это будет абстрактный класс) Model и знает как сделать CRUD. Теперь нам надо решить как мы будем взаимодействовать с БД:

1 вариант мы генерируем класс конкретной модели например Shape на основание данных, для примера рассмотрим данные в бд, то есть возьмем все таблицы в БД и для каждой создадим модель у которой свойства будут проекцией полей, а методы взаимодействие класса с таблицей данных, при определенных действиях в админке.

2 вариант мы переделываем класс Model из абстрактного в реальный, который может взаимодействовать с любой таблицей в бд

А теперь порассуждаем о данных и таблицах в БД. Будем исходить из тех данных которые у нас уже есть. А именно:
1. Ролик. ( Четыре поля: идентификатор, название, ссылка на ютюб, идентификатор категории )
2. Категория. ( Два поля: идентификатор, название)

Пока никаких сложностей, все предельно просто.

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

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

ksnk, конечно приведенный мной пример отличается от твоего, но основное моменты в нем похожи, а именно ты пытаешься создать серебряную пулю, но кто тебе гарантирует что завтра тебе не понадобятся золотые. Пусть у тебя будет один метод отвечающий за два разных с точки действия админки действия. Чтобы не быть голословным, пусть за хранение категорий товаров (Утюги, Сковородки, Чайники и т.д.) и названия брендов (Чугуевский завод подтяжек, Амстердамский стекловар и т.д.) отвечает одна таблица. Соответственно в админке лучше иметь две разные страницы (заголовок страницы, названия полей), иначе при работе с админкой клиент будет постоянно дергать разработчика, вопросом а как добавить категорию товара или как добавить производителя и ему не помогут инструкции, так как его задача не тратить время на изучение или вспоминание, а зарабатывать деньги при помощи этого программного продукта. Страницы разные, а вот должен быть один, но у тебя будет проблема так как у тебя метод определяет однозначное поведение для вывода страницы. Следовательно тебе придется придумывать дополнительную логику в виде методов оберток, либо еще что либо.

Зачем? По названию метода определяй. Ты вообще вроде про рефлексию говорил изначально?

Это сообщение отредактировал(а) krundetz - 29.7.2013, 15:56

ksnk, наверное я не совсем понял мысль или ты слишком усложнил решение.. У меня пока пара вопросов:
1. А не накладно парсить файлы?
2. А что мешает вызвать метод которые якобы относится к админке из другого класса с фронта сайта? Получается что я подключаю класс на фронте и при этом получаю доступ к админским ресурсам

Не накладнее чем работать с БД
В любом случае результат парсинга можно кешировать.

а по второму пункту? 

А по второму пункту это вопрос  не ко мне.

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

ну это понятно... 

Но я всё равно не понимаю необходимости такого подхода, не вижу плюсов

Write less, do more

Впрочем, я не уверен что в предложенном варианте именно write less
По моему опыту работы меньше не станет, она будет просто немного другой.

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

Я начал делать такое но забросил, так как хотелось переделывать с позиционирование и вложенности, на фиксированы блоки-строки.
Скрины для вдохновения:
http://s1.ipicture.ru/uploads/20130801/3tqqI61m.png

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


Это сообщение отредактировал(а) Sanchezzz - 1.8.2013, 02:56

Вернулся из отпуска, сейчас почитаю 


Ну, почему же, пулька получается местами даже позолоченная.  Просто не нужно пытаться заткнуть таким макаром вообще все админские возможности. Иначе не хватит изобразительных возможностей doctype. Так, пункты меню добавить...

Вообще в моем примере декларируется, что 

•  страница админки соответствует методу класса admin. Дополнительное оформление страницы берется из doctype описания метода
•  страница админки представляет собой форму.
•  содержимое формы (список обтображаемых контролов) определяется по параметрам соответствующего метода класса admin. порядок и расположение этих контролов регулируется порядком параметров или шаблоном.
•  при POST'е этой формы вызывается сам метод с нужными параметрами.

При соблюдении этих условий (imho - достаточно универсальных), достаточно изменить ОДИН метод одного класса для добавления новой странички. 


Так для каждого метода придется мастерить еще и шаблон - пропадает легкость добавления фич.


Файлы парсятся reflection. Кто его знает как оно сделано, но работает шустро. doctype комментарии выхватываются даже у родителей.
Для админки скорость отображения страницы несущественна, сколь нибудь ощутимой нагрузки все равно от нее нет, хотя несложно и закешировать по времени изменения исходного файла. Меня пока устраивает и так. К тому же сам файл никогда не будет очень большим. Если логика не вмещается на несколько строк - нужно выносить ее в отдельный слой скриптов, иначе пропадает понятность.


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

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

Sanchezzz, не-не! Конструктор форм - это то самое, про что говорит krundetz. Через некоторое время юзер захочет странного , что не влезет в простой линейный список. Да и сложно это.