- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
А как же типы полей? Например переменая "footerBoxed" с типом значения булево. Или при редактировании в "формочке" все типы полей выводятся как input[type=text] или textarea?
Храниться оно в текстовом файлике в json, откуда я и скопировал.
Структура (где типы и т.п.) выглядит вот так:
(квадратные скобки заменил на фигурные ибо форум портит)
Немного сыровато, например правило img не требует string ибо наследуется от него, и т.п., но пока цель быстро делать сайты и тестировать, а не чистота кода.
К этому еще файлик языков:
Ну и собственно "код" самого контроллера для админки:
Ну и результат соответственно выглядит вот так:
Оно вроде и много букафф как для простой формочки на 15 полей, но пишется это быстрее чем куча копипасты шаблонов, думать не надо,
да и чего греха таить - не так уж и мало оно делает - и валидация, и приведение типов, и автозаполнение и разные виды полей, типа картинки, текстового редактора и т.п.
Ну и да, шаблоны тут уже готовые, и контроллер типовой, но они тоже не сложные:
Шаблон который мы тут видим:
Ну и контроллер тоже хоть и универсальный, но не сложный:
Ну и "абстрактный" конфиг контроллера от которого мы "наследовались" выше:
(напомню что квадратные скобки заменяны на фигурные).
Бонусом ту же форму в инсталяторе добавляю одной строкой, и уже в шаблоне инсталятора она выводится с учетом всех правил, подсказок и т.п.
ПС: Это не реклама моего движка, я просто пример MVC привожу. Того же Yii под рукой нет.
ПСС: Напомню что я тут и код админки привел, и код самой формы, и даже код "плагина" который такие вещи автоматом делает, так что многобукафф весьма условно.
шаблонизатора явно не хватает
mendel,
МВЦ в действие, любо-дорого :)
А что за функция s не понятно? синглтон?
Конфиги держать в json вполне оправдано, но языковые файлы не проще в ini держать? Получим тот же ассоциативный массив с возможностью использовать секции:
файл russian.ini:
файл test.php:
результат:
Плагин небось взял из "бесплатных из интернета"?
Естественно. Ещё за плагины к вордпрессу платить?
Вот так смотришь другие cms и думаешь "госпади, ну и накашмарили". В результате чего занимаешься не программированием, а изучением тараканов от создателя движка.
У одних тонны конфигураций в ветвлениях массивов или json , другие языковые файлы создают вместо использования gettext, у третьих мания OOP и всего нового, что приводит к тоннам абстракций, наследования и километровым вызовам объекта за объектом.
Естественно. Ещё за плагины к вордпрессу платить?
Проржал с этого поста)) в нем вся суть wordpress.
МВЦ в действие, любо-дорого
я просто пример MVC привожу
Есть только одна проблема: при использовании MVC у вас должен быть шаблонизатор, потому как на данный момент ничто не мешает сайту отвалиться из-за Syntax Error, ну или какой-нибудь мудак сможет во View сделать eval или ещё какую-то хрень. Ну, то есть, само по себе решение с шаблонизацией в виде PHP нельзя назвать не правильным, но зависимость работы приложения от View все равно остается. Ещё, кстати, PSR немного глаз мазолит, но это уже такое)) хозяин - барин.
Вот так смотришь другие cms и думаешь "госпади, ну и накашмарили". В результате чего занимаешься не программированием, а изучением тараканов от создателя движка.
У одних тонны конфигураций в ветвлениях массивов или json , другие языковые файлы создают вместо использования gettext, у третьих мания OOP и всего нового, что приводит к тоннам абстракций, наследования и километровым вызовам объекта за объектом.
И действительно, а зачем нам "тонны абстракций, наследования и километровым вызовам объекта за объектом". Пусть лучше будет изобилие функций, как например у ВП.
Только что установленный ВП интереса ради, без каких либо настроек и плагинов. Так вот он имеет 1900 узер функций ( весь список функций выложил на pastebin.com, вдруг кому будет интересно ). К-во подключенных файлов я даже боюсь смотреть.
2к функций лучше 1 класса, расширенного абстрактным классом и интерфейсом? ну я прям даже и не знаю что и сказать.
По вашему это нормальная практика?
По поводу gettext, быть может вы правы :)
И действительно, а зачем нам "тонны абстракций, наследования и километровым вызовам объекта за объектом". Пусть лучше будет изобилие функций, как например у ВП.
А где то кто то говорил о функциях ? Я ставлю просто под сомнение ООП ради ООП.
obius, WP тащит legacy, наверное так спроектировали в 2003
Самое интересное, зачем нужна обратная совместимость, если всех подталкивают ставить новые версии WP из-за дырок в предыдущих версиях.
Так вот он имеет 1900 узер функций ( весь список функций выложил на pastebin.com, вдруг кому будет интересно ).
к чему вы так напрягались?) кому надо в курсе, и скажу больше все эти функции задокументированы и описаны и не раз, например русский вариант или в оригинале
о чем вообще речь? любой фреймворк или серьезная CMS имеет такой набор функций или классов, который приходится изучать и применять.