А какое отношение вот это всё имеет к ООП?
Тут статика сидит на статике и статикой погоняет :)
Ну и да, в динамическом коде все равно местами не знаешь что вернешь - фабрики, сервислокаторы и т.п., и пхпдокс не поможет. Но найти то не проблема - в начале любой документации описывается логика конфигов/автоматических имен классов и т.п.
Синглтон, не?
глобальные переменные зло.
Для сахара, чтобы короче было, обычно делают или статикой типа Yii::$app->имяСервиса, или как я - в функцию оборачивают т.е. s()->имяСервиса
Еще адресное пространство засерают, функциям в ВП никто неймспейсов не дает.
Но то такое. На самом деле это было возражение на слова "куча связанных классов". На что ответили мол "вы на свои функции смотрели? А они то загружены всегда, а не автозагрузчиком". Так то я удивился что у меня 80 классов грузится, даже список из любопытства глянул, ну и забыл. Глупости это. Даже без кеширования глупости. А с кешированием автозагрузчик еще меньше грузанет. Но я бы изначально такой аргумент не стал бы приводить потому-что ерунда. Имеет смысл только в ключе "на себя посмотрите".
Покрытие тестами решает. У меня оно правда ноль :)
А так то я не понимаю как можно найти мертвый код у интерпретатора с автоподгрузкой и т.п. Построитель запросов для древней СУБД это мертвый код?
И чем он с точки зрения кода будет отличаться от такого же, но под sqlite?
Не помню что там, но если намек на сходство, то я стараюсь сделать высокофункциональную вещь с таким же удобством "для мужиков" как у ВП, так что сходство предсказуемо :)
Нагрузка на диск, компиляция в опкод, место в ОЗУ. Это не так много, но больше чем с автозагрузкой классов. Да и изначально то это был ответ на "гулпые ООП-программисты делают кучу классов с кучей наследования".
Сейчас глянул у себя:
160 классов встроенных в пхп, 80 классов моих. Странно что так много.
У меня 137 классов в этом проекте. И 80 из них подгружается? Капец)
Свят-свят-свят!
Мне хватит ст.27 УК Украины :)
А по факту - да, Вы правы. Дело не в статье а в правоприменительной практике.
Это в Украине еще нужно будет доказывать знал ли я о реальных целях - помните сайтик
fast-die.kiev.ua? Сейчас там другой контент, но в начале цензуры в РФ он стал известен как стеб на тему суицида. Любому человеку понятно что это анекдот, но "эксперты" РКН а точнее РПН решили что это пропаганда суицида, и сайт был забанен - вместе с EVA online которую тогда забанили за "наркотики", т.е. различные ускорители, увеличители интеллекта и прочие ресурсы для игровых персонажей в игре.
Также стоит вспомнить что мультипликационное порно в РФ проходит как детское :)
Глянул ст.33 ук рф - не сильно отличается от ст.27 УКУ. Нет п.6 и п.7, но это скорее уточнение из ПНК. Они тут совсем не применимы, поскольку умысел, сговор и прочее - фантазии следователя. Ну сделал я человеку сайт по работорговле. но откуда же мне знать, что он там реальных рабов продавать будет? Специально смотрел в поиске - ни одного такого сайта. Только шутки, да статьи на эту тему с "желтыми заголовками". (Реально искал - реально нифига не найти, как и дп. Может где-то в даркнете или на спец.форумах как-то где-то и ищется, но сеть хорошо от этого очищается сама). "Искренне" считал что это очередной сайт журналиста будет.
Ни один суд (кроме "басманного" - не по флагу, у нас тоже бывает, а по мему) - такое обвинение не поддержит. И российский тоже бы не поддержал, но "незаконный" контент попахивает Мосгорсудом и РКН, а такие дела все сплошь политические, даже когда политики и рядом не было - надо "живую" статистику делать, чтобы в ней затеряться.
Так что да. Не заморачиваться, и отказываться от всего что плохо лежит. ---------- Добавлено 30.11.2016 в 11:16 ----------
Вот кстати интересный вопрос.
Можно ли резиденту РФ или Украины - продвигать марихуану в американском гугле, на домене в *.us, хостинге в США, и нацеленные на клиентов США, и даже только в тех штатах где она разрешена?
Сахар для сервис-локатора. Но да, синглтон конечно. В принципе единственный.
Не проще. Оно аналогично будет редактироваться из админки.
Здесь не понял. У меня тоже секции. С привязкой к конкретному объекту. Т.н. LangSpace. Только в собственном решении есть возможность сделать наследование секций. Например файлик словарика модуля статей/новостей выглядит так:
'model/article' => { '#parent' =>'model/defaultPage', }, 'model/news' => { '#parent' =>'model/defaultPage', }, 'model/pageCategory' => { '#parent' =>'model/defaultPage', }, 'view/article/sidebar/list' => { 'title'=>'Новости', 'all'=>'Все новости >>>>', },
Лишняя зависимость от конфигурации сервера.
Можете обосновать чем оно лучше? Решений разных много, просто стараюсь сохранить единообразие, там где нет веских причин его не делать.
Да, будет. Примерно по таким соображениям.
Точнее я сейчас очень существенную часть логики вынес в конфигурационные массивы, недавно был большой блок по выкуриванию из них логики (в плане кода который не данные). Скоро буду переводить их на json. Но пока есть несколько "некрасивых" мест в синтаксисе этих конфигов. Но в целом для подавляющего большинства прикладных задач будет достаточно только конфигов и шаблонов. Так что тут явно напрашивается избавление от пхп в прикладном слое. Шаблоны редактируем в ACE editor, под конфиги красивую админку можно забабахать... На прошлой итерации этого бесконечного цикла, я остановился на том, что шаблонизатор таки нужен, чтобы не было всяких XSS и прочих неожиданностей. Да и все мы знаем что больше половины сайтов на ВП имеют бекдоры именно потому что гуляет куча тем с закладками, и мало кто чистит код, удаляет ненужные темы и т.п. Не нужно давать пользователю возможность отстрелить себе ногу.
Но когда я начал писать этот движок, то у меня было четкое понимание, что ActiveForm и прочих виджетов можно утонуть под горой кода вьювов, и оно того не стоит.
Плюс проект начинался с принципов "ни одной строчки старого кода, как чужого так и своего".
Необходимость шаблонизатора усугубляется еще и тем, что у меня понятия вьюва и шаблона разделены. Есть стандартный класс вьюва, есть возможность для разных вьювов указать свой специфический. Т.е. специфичный код ДОЛЖЕН жить отдельно, во вьюве, а в шаблоне относительно небольшой набор возможных операций. Но доберусь я до этого не скоро. Готовые шаблонизаторы немного тяжеловаты, а свой - долго. Может форкнуть твиг, и выкинуть лишнее?) В общем это в долгом ящике.
Ну да, со стандартами каша. Каюсь :)
Оно начиналось на половину в шутку. Тестовое задание на собес, примеры для обсуждений/обучения юниоров. Потом вдруг понял, что в этой шутке слишком много правды. У меня даже неймспейсов нет, композера нет, пхпдоксы почти не заполнены, тестами даже не пахнет.---------- Добавлено 30.11.2016 в 00:08 ----------
Речь вообще не про изучение.
Если я правильно понимаю, то список составлялся через get_defined_functions?)
Разжую. Не просто функций. А функций уже загруженных. В ПХП нет автоподгрузки функций, как для классов. Вы можете никогда не использовать 1500 из этих 1900. И ваши плагины, и темы могут их всех никогда не использовать. Но при КАЖДОЙ странице этот код будет выполнен.
Храниться оно в текстовом файлике в json, откуда я и скопировал.
Структура (где типы и т.п.) выглядит вот так:
'skinReg' => { 'box' =>{ '#class' => 'RegBox', }, 'rules' => { 'default' => { 'id' => {'hidden', {'defaultSave','value'=>'skinReg'}}, 'folder'=>{'hidden','randId'}, 'siteName' => {'string'}, 'skin'=>{{'selectArray','options'=>{ 'cerulean'=>'Cerulean - A calm blue sky', 'cosmo'=>'Cosmo - An ode to Metro', 'cyborg'=>'Cyborg - Jet black and electric blue', 'darkly'=>'Darkly - Flatly in night mode', 'flatly'=>'Flatly - Flat and modern', 'journal'=>'Journal - Crisp like a new sheet of paper', 'lumen'=>'Lumen - Light and shadow', 'paper'=>'Paper - Material is the metaphor', 'readable'=>'Readable - Optimized for legibility', 'sandstone'=>'Sandstone - A touch of warmth', 'simplex'=>'Simplex - Mini and minimalist', 'slate'=>'Slate - Shades of gunmetal gray', 'spacelab'=>'Spacelab - Silvery and sleek', 'superhero'=>'Superhero - The brave and the blue', 'united'=>'United - Ubuntu orange and unique font', 'yeti'=>'Yeti - A friendly foundation', }}}, 'favicon' => {{'string', 'maxlen'=>120},'img'}, 'bgImg' => {{'string', 'maxlen'=>120},'img'}, 'bgSize'=>{{'selectArray','options'=>{ 'cover'=>'По ширине', 'contain'=>'Поместить целиком', }}, }, 'footerBoxed'=>{'boolean'}, 'copyright' => {'string'}, 'footerColor'=>{'string'}, 'footerBgColor'=>{'string'}, 'footerType'=>{{'selectArray','options'=>{ 'layout/block/footerSmall'=>'Small - no contact, no menu', 'layout/block/footerMenu'=>'Menu - contact, menu', 'layout/block/footerWell'=>'Well - contact line', }}, {'default','value'=>'layout/block/footerSmall'} }, 'infoBlock' =>{'article'}, 'infoBlock2' =>{'article'}, 'defaultThumb' => {{'string', 'maxlen'=>120},'img'}, }, }, 'formTabs' => { 'default' => { 'default'=>{ 'siteName', 'skin', 'bgImg','bgSize', 'favicon', }, 'footer'=>{ 'footerBoxed', 'footerType', 'copyright', 'footerColor','footerBgColor', }, 'other'=>{ 'defaultThumb', 'infoBlock', 'infoBlock2', }, }, }, },
(квадратные скобки заменил на фигурные ибо форум портит)
Немного сыровато, например правило img не требует string ибо наследуется от него, и т.п., но пока цель быстро делать сайты и тестировать, а не чистота кода.
К этому еще файлик языков:
'model/skinReg' =>{ '#parent' =>'model/abstractFormModel', 'footer_Tab' => 'Подвал (footer)', 'other_Tab' => 'Прочие настройки', // 'siteName'=>'Название сайта', 'siteName_help'=>'Название сайта', 'skin'=>'Шаблон', 'skin_help'=>'Шаблон - основная цветовая схема, и некоторые стандартные элементы оформления', 'favicon'=>'Favicon', 'favicon_help'=>'favicon', 'bgImg'=>'Фон', 'bgImg_help'=>'Фоновая картинка всего сайта', 'bgSize'=>'Размер фона', 'bgSize_help'=>'Размер фоновой картинки - по умолчанию замостить копиями картинки, или растянуть по ширине, или поместить всю картинку целиком', 'footerBoxed'=>'Фиксированная ширина', 'footerBoxed_help'=>'Фиксированная ширина шаблона, т.е. не на всю ширину', 'copyright'=>'Копирайт', 'copyright_help'=>'Пишется внизу сайта и других местах', 'footerColor'=>'Цвет шрифта футера', 'footerColor_help'=>'Цвет шрифта в "подвале", там где копирайты', 'footerBgColor'=>'Цвет фона футера', 'footerBgColor_help'=>'Цвет фона "подвала"', 'footerType'=>'Вариант подвала', 'footerType_help'=>'Выбираем вариант компоновки подвала (нижней части страницы)', 'infoBlock' =>'Инфо блок сайдбара', 'infoBlock_help' =>'ИнФормация выводимая в первом блоке в сайдбаре - наиболее полезная', 'infoBlock2' =>'Инфо блок2', 'infoBlock2_help' =>'Блок сайдбара который внизу', 'defaultThumb'=>'Заглушка для статей', 'defaultThumb_help'=>'Заглушка для статей подставляемая если у статьи нет картинки', },
Ну и собственно "код" самого контроллера для админки:
'adminSkin' => { '#parent' =>'adminRegAbstract', 'modelName' => 'skinReg@skinReg', },
Ну и результат соответственно выглядит вот так:
Оно вроде и много букафф как для простой формочки на 15 полей, но пишется это быстрее чем куча копипасты шаблонов, думать не надо,
да и чего греха таить - не так уж и мало оно делает - и валидация, и приведение типов, и автозаполнение и разные виды полей, типа картинки, текстового редактора и т.п.
Ну и да, шаблоны тут уже готовые, и контроллер типовой, но они тоже не сложные:
Шаблон который мы тут видим:
<div class="row"> <div class="col-lg-12"> <?=view('crud/crudTab',{'model'=>$model,'actions'=> controller()->updateActions});?> </div> <?php if($article): ?> <div class="col-lg-12"> <div class="box"> <div class="box-body"> <?=$article;?> </div> </div> </div> <?php endif;?></div><?php if(controller()->needUploader) : ?><?=view('uploader/uploader',{'folder'=>$model->folder,'addEditor'=>TRUE});?><?php endif; ?>
Ну и контроллер тоже хоть и универсальный, но не сложный:
class AdminRegController extends AbstractPageController{ public $formTabs; public $needUploader = TRUE; protected $modelName; public $updateActions={{'crud/save'}}; public function __construct($config = NULL) { if(s()->currentUser()->isGuest()) throw new RouteForbiddenException(); s()->http()->ttl = FALSE; // Запретим кешировать наш вывод ибо он динамичный parent::__construct($config); } public function indexAction() { $page = $this->preparePage(); // ********************************************************************** $model = model($this->modelName); // Пробуем обновить данные из POST, если обновили и данные валидны, то сохраним if(s()->post()->update($model) AND $model->isValid()) { $model->save(); } $page->model = $model; s()->layout()->show($page); } }
Ну и "абстрактный" конфиг контроллера от которого мы "наследовались" выше:
'adminRegAbstract' => { '#parent' =>'adminAbstract', '#class'=>'AdminRegController', 'viewName' => 'crud/update', 'needUploader' => TRUE, },
(напомню что квадратные скобки заменяны на фигурные).
Бонусом ту же форму в инсталяторе добавляю одной строкой, и уже в шаблоне инсталятора она выводится с учетом всех правил, подсказок и т.п.
ПС: Это не реклама моего движка, я просто пример MVC привожу. Того же Yii под рукой нет.
ПСС: Напомню что я тут и код админки привел, и код самой формы, и даже код "плагина" который такие вещи автоматом делает, так что многобукафф весьма условно.
Маркет-XML.
Есть какая-то дыра как тырить запросы и отдавать за денежку.
Спрос достаточно большой. Предложений не много.
Явно не парсят, может какой мобильный клиент имеет близкий АПИ, может еще какие дыры. Не курил тему глубоко. Существующие предложения имеют кучу минусов. Клиентуру получите быстро и много.
Что за дискриминация по цвету кожи?)
А если серьезно, то по идее сайты то делать можно, а вот использовать уже нельзя.
Ну рекламировать еще не стоит не только запрещенку, но и все что требует лицензии.
Мысль мелькнула - делать сайты экстремистам и сразу стучать в роспозор.
Потом если что можешь рассказывать мол я же сообщил, а делать то не запрещено)
Есть два вида людей.
Те кто уже делают бекапы и те кто еще не делают :)
Если владелец сайта на вордпрессе (сферический владелец сферического сайта) захочет поменять дизайн, а потом развить то что у него есть до большого портала с бильярдом и поэтессами, то всё что у него есть будет благополучно выкинуто в мусор. Даже если еще живы те кто ему делал сайт. Даже если они делали правильно, по кодексу.
Я в целом за вордпресс, о чем тут уже писал. Но у него есть ряд недостатков, которые его и погубят. Потом. Не сейчас.
Не буду холиварить на эту тему :) С 2007 года я шесть раз менял свое мнение на противоположное. Сейчас я на пхп-шаблонизаторе живу, но таки буду в следующем году опять писать свой шаблонизатор на конченных автоматах (пятый уже наверное) или на регулярках (второй). Не решил еще на чем. Но буду :) Вернулся в пхп потому что в шаблонизаторах тесно, а писать полноценный -долго.
Так то логику я вашу разделяю. Главное именно МВЦ или хоть частичное его подобие.
Равно как в шаблонной части пхп использовать по возможности в альтернативном синтаксисе (а мужики то сволочи и не знают, что он есть, и что он читабельнее).
Это даже вроде в кодексе есть. Но кто ж его читает?)
