Ну нет, и нет.
Ну вот на пальцах покажу.
Я тоже как и ВП делаю львиную долю логики описательным методом, а не кодом.
но я это все храню не в базе.
Я пока не писал админку для редактирования именно моделек (частный случай это ваши записи), но всякие конфиги у меня редактируются по такому-же принципу:
В админке есть обычная формочка.
Мне не нужно писать плагины, потому что это делается несколькими строчками.
Она выводит формочку редактирования. Ну скажем настройки шаблона.
Введенные данные проверяются, и сохраняются в файлик. Примерно в таком виде:
{ "id": "skinReg", "folder": "e5a84985a7cc6a6fabc8f308b6b6d241", "siteName": "TestSite", "skin": "readable", "favicon": "/files/uploads/e5a84985a7cc6a6fabc8f308b6b6d241/favicon.png", "bgImg": "/files/uploads/e5a84985a7cc6a6fabc8f308b6b6d241/bricks2.jpg", "bgSize": "", "footerBoxed": true, "copyright": "(c) Runtime 2016", "footerColor": "#fff", "footerBgColor": "#000", "footerType": "layout/block/footerSmall", "infoBlock": "", "infoBlock2": "", "defaultThumb": "/files/uploads/e5a84985a7cc6a6fabc8f308b6b6d241/rt-logo.png"}
Хранение в базе или в файлике - без разницы. Одна строка в конфиге. Форма редактирования тоже стандартная, она же используется и для страниц, и для товаров и т.п. Всё.
При этом я могу такие файлики к примеру вносить в репозиторий. И при изменении например footerType, в следующем коммите у меня будет красивенькая запись об этом. Возможность откатить, возможность найти когда и зачем я ее менял.
Опять таки. В этом поле у меня указано имя вьюва/шаблона. При рефакторинге мне может показаться к примеру, что лучше называть его не footerSmall а footerSimple. Я банально захочу найти везде это имя и поменять его на новое. Простым поиском. Но постойте... Мне нужно помнить где я храню это в базе, как оно называется, и как мне искать это в базе :)
Таких моментов тысячи. Когда делаешь сайтик с 10-20 "типами записей" или как там они у вас называется: всё это кажется несущественным. Но когда таких вещей становится за сотню, то начинается легкое ох.. офигивание.
Помню в году этак 2007-2008 я сильно возмущался что пользователи моего сервиса не следуют инструкции "обязательно нажмите вернуться на сайт после оплаты".Ну что они тупые или слепые? Я ведь красным h1 написал на полстраницы написал, прямо перед оплатой. Почему в день по пять человек в саппорт пишут "у миня непаполнилося"? Потом таки переписал так чтобы вебмани подтверждали оплату и без юзера. Многие ляпы "мужиков" в полноценных движках просто невозможны, или затруднительны. Что не отменяет других недостатоков у полноценных...---------- Добавлено 29.11.2016 в 12:12 ----------
Есть понятие "стандартные плагины".
Но дело даже не в том.
Такие ядерные настройки в базе - усложняют отладку, разработку, версиозность и т.п.
На то они и мужики :) Мужикам надо знать как печь топить, дрова колоть. Зачем им архитектура ВП?)
borisd, наследование бывает не только у классов :)
Не помню как у ВП, точно помню что шаблоны у них наследуются от родительской темы, но вроде и типы записей тоже наследуются.
У меня наследование моделек идет вот так:
'news' => { '#parent' => 'article', 'rules' => { 'default' => { 'parent_id' => { 'int', {'defaultParent','where'=>{'route'=>'news:index'}}, }, 'showDate' =>{'virtual',{'defaultCopy','field'=>'created'}} }, }, },
А вариант
безусловно самый ужасный.
В ВП для создания новых типов записей используют плагины, которые оборачивают довольно толстый код создания типа записи. Это было бы терпимо, если бы не два момента - таких плагинов несколько, и поскольку они не являются частью ядра, то мы получаем зоопарк "фреймворков" - все пишут на ВП, но реально каждый на своем варианте. Далее - весь этот "код" хранится в базе. Т.е. гит в пролете поиск по коду в пролете, копипаст в пролете и т.п.
Еще у ВП как следствие парадигмы "скопируй шаблончик и радуйся" нет универсального подхода к наследованию. Если у стилей есть наследование, то не факт, что оно будет у модели, и явно будет устроено по другому. И если в событийной модели есть событие, то отлично, а если нет, то всё, забуть. В ядро не попасть. (С грамотным наследованием можно прописать свой класс отнаследованный от стандартного и всё, но это если ты можешь сообщить что нужно использовать другой класс, например у меня рядом с #parent можно написать #class и это работает и для моделей, и для вьювов и для контроллеров и для сервисов и т.п., а вот у ВП так подменить что-то не всегда выйдет, есть у них внутри какой-то класс, но подменить его нельзя, только перехватывать что-то). Но и это не главные проблемы ВП. Вылазить за стандартные события особо не нужно, но вот отсутствие единообразия, внятной структуры - проблема. Как в том анекдоте - зал для удовольствия совмещен с туалетом: вся логика в фанкшн.пхп. Да, "мужики" инклюдами создают некое подобие структуры. Но это исходя из видения конкретного "мужика". Так то почитают википедию, да будут всякие опенкарты МВЦ называть (суки!).
Кодекс это костыль для попытки упорядочить то, что не упорядочить естественным образом.
Но и это пол.беды. Нет простейших инструментов. Вот это уже беда.
ORM/ActiveRecord:
Ну вот есть у нас допустим страница категории товаров. У нее есть товары, мы их себе спокойно выводим. Все хорошо. Тут прилетает задача сделать вложенные категории. Ну фиг с вами, выводим список категорий вверху, внизу товары категории. Не проблема.
Тут прилетает задача - выводим для вложенных категорий не только название, описание, ссылку и иконку, а еще и топ5 товаров из вложенной категории. Черт! тут уже пляски пошли с бубном. Нет, нет, вы не поняли. У товаров ведь есть список категорий к которым он относится, их тоже нужно вывести, чтобы красиво и удобно было. Да, еще у товара есть производитель. А у производителя есть логотип. Его тоже нужно обязательно вывести в этом превью товара.
А это уже на день работы вырастает.
Или нет?)
Или можно написать что-то вроде:
//$category - моделька выводимой категорииforeach($category->subcategorys->findAll() as $cat) { echo $cat->title; echo $cat->url; // тут конечно будет верстка ссылки, но это детали $products = $cat->products->limit(5)->order('popularity')->findAll(); echo showModels('product/viewSmall',$products);}
Ну а product/viewSmall мы уже писали до того, когда писали вывод товаров в категории.
Но раз в ВП тоже можно нормально дробить и переиспользовать (правда хрен так кто делает), то напишу и его (схемотично конечно).
echo $model->title; echo $model->url; echo $model->preview; // ....foreach($model->category->findAll() as $cat) { echo $cat->title; echo $cat->url; // тут конечно будет верстка ссылки, но это детали}echo $model->manuf->logo->small;
Да, в ВП это можно сделать. Да, есть даже неплохие плагины которые упрощают это до _ПОЧТИ_ такого же уровня. Но! Это уже не вордпресс, а некий плагин. Со всеми вытекающими.
Помимо ОРМ в ВП не хватает других полезных инструментов, вроде валидации, активформ и т.п.
Например я делаю.. ну скажем у меня сайт автосалона, и мне нужно сделать форму записи на Тестдрайв.
Нужно чтобы было поле емайла, чтобы мыло проверялось на валидность, нужно обязательное заполнение телефона и имени (мыло если не заполненное, то не проверяем), проверить что сообщение/комментарий не слишком длинное, для поля желаемой машины был выпадающий список (с учетом наличия галочки в каталоге "разрешен тестдрайв", и такой-же выпадающий список для конкретной площадки где человеку удобно, ведь у нас сеть салонов).
В принципе свои пять-семь строчек кода описывающих структуру таблички с тестдрайвами мы уже делали (ведь у нас это надо смотреть в базе), так что хватит с нас и такого кода:
<?=view('widget/formModel',['model'=>$model,'noHelp'=>TRUE]);?>
Всё.
Красивая бутстраповая формочка, с нужными типами полей, с ошибками если были ошибки, с прочими полями. Всё готово. Когда клиент захочет добавить поле "Город", чтобы расширить сеть на другие города, то я даже в шаблон заглядывать не буду. Вообще. Просто добавлю строчку в описании модели, да добавлю колонку в базу.
ПС: И тем не менее.ВП хорош. Стар, неуклюж, но хорош.---------- Добавлено 29.11.2016 в 11:35 ----------
Серьезно. :)
Потому что:
Core-разработчики знают все паттерны. :)))
Просто хрен они их могут позволить применять в прикладном коде.
Всё старое отвалится. _Ничего_ не останется. Совсем.---------- Добавлено 29.11.2016 в 11:42 ----------
EAV - хороший паттерн. Его преимущества и недостатки тривиальны.
Для гибкого блога с низким порогом вхождения это самое то.
Хотя я тоже предпочитаю полноценные поля а не EAV.
А так то тут половина даже не понимает о чем мы :) "Движок то сам всё выбирает", а то как выбирает, и чего это стоит - не важно. )---------- Добавлено 29.11.2016 в 11:43 ----------
Вот ведь блин :)
Обе позиции в туду отодвигаю уже второй месяц)))
Упали, упали. Это я вам говорю и как разработчик, и как тех.дир., и как постановщик, и как бывший заказчик. Мое любимое занятие это код. Но зарабатываю я больше с работы "переводчиком" - с языка бизнесменов на язык программистов. Упали. Есть определенные сложности как у core-разработчиков, так и у сайтоделов. Плагинописатели и т.п. естественно тоже попадают будучи посередине.
Но уход с текущей парадигмы это _полностью_ новый движок. Просто "от создателей...", а это далеко не всегда срабатывает.
Есть хорошие вещи. Есть очень хорошие. Но нет столь популярных. Молодые альтернативы не имеют возможности развиться в его тени. Ну или занимают узкие ниши или остаются платными.
Но рано или поздно он упадет под собственной тяжестью. Но не скоро :)
Вот. Вы подтверждаете мои слова - по кусочку каждый в чем-то хорош. Но всё вместе - нет конкурента, у которого плюсы перевесят минусы. Вопрос обратной совместимости очень тяжелый на самом деле. Особенно это катастрофично на начальных этапах. У меня сейчас каждый месяц полностью новое АПИ.
Из виденного - не могу. Мало того - я уже год пилю свое. Ну почти. Реального времени с полгода будет. Но хронологически таки год. Стандартные задачи вордпресса решает хорошо. Сам отказался от ВП, и окружающих пересадил на свой движок. Но даже когда я его выпущу в бетту, потом в релиз, потом пройдет пару лет, и он обрастет мясом, модулями, темами - он в чем-то будет уступать ВП. В чем-то он конечно лучше уже, но даже если "мы победим", то до последнего момента свои плюсы у него останутся :)
Да я в общем не о тренде а о банальном ООП/DRY/SOLID/MVC.
И да, я слышал байку мол у ВП есть МВЦ, но это некие внешние костыли.
И да, ВП не ООП, Объекты у него или чуть внутри, или "объекты" используются как в пхп4, в качестве некоторого контейнера для общего имени функций и т.п., но никак не полноценный ООП.
Это может только суд решить. А пока суд не решил, ты преступник!
Это палка о двух концах.
На одном конце обратная совместимость, на втором конце мегатонны легаси.
Конечно ставишь "мастхев" плагины (а по хорошему "мастюз", если вы понимаете о чем я :), потому, что в ядре их нет.
У других в ядре они есть, но проблемы с тем что еще больше проблем от обратной совместимости ибо оно в ядре, и т.п.
Архитектура ВП безнадежно устарела. Но в свое время и для своей ниши она была идеальна.
За счет этого удачного попадания в профиль - вокруг ВП выросла своя экосистема. Преимущества экосистемы перекрывают недостатки его древности.
Но да, проблемные места остаются. И с каждым днем разрыв увеличивается.
Несколько раз напарывались на несовместимости.
Помню был "забавный" случай когда было сделано несколько изменений, сайт перенесен на другой хостинг и т.п., и тут вдруг пару фич заглючили.
День нервов, а потом оказалось что клиент увидел в админке просьбу обновиться, взял, да и обновился.
Я понимаю что "у всех бывает", и у ВП огромный зоопарк плагинов, с которыми бывают проблемы, а у меня их вообще почти нет. Но автообновлению доверять можно не всегда.
Сходу не вспомню. Окончательно от ВП ушел уже с год как.
Но из именно репозитория плагинов у каждого второго были XSRF/XSS, да и SQL Injection не часто, но находил в глубине кода.
Да, в кодексе есть советы. Но поскольку ядро само это не отслеживает, то те кто плагины рецензирует (кстати как это выглядит? я только в этой теме услышал что мол пропускают только проверенные) - замечают не все ляпы.
Да, действительно, для полноценной атаки, да еще так чтобы массово, это не всегда применимо. Но под точечные взломы в сочетании плагинов часто можно что-то поймать.
Каноникал (десятьсимволовнада)
