Каждый запрос, который получает движок, сначала обрабатывается роутером (Router). Примерно так же, как каждого посетителя в крупных компаниях встречает девушка на ресепшен, которая узнает, чего надо посетителю, какой у него вопрос, и затем направляет его к тому нужному менеджеру, так и роутер направляет запрос нужному экшену (Action). Экшен, приняв
Получив все, что нужно, экшен поручает вьюеру (Viewer) доставить результат запроса посетителю сайта в красивой упаковке.
Хоть сам роутер очень программно очень наворочен, его принцип, по сути, довольно прост. Чтоб не писать слишком много букв, вот картинка, которая многое проясняет:
Т.е. нужный экшен по умолчанию определяется по той части URL, которая идет после имени домена. Конечно, есть возможность многое перенастроить и переопределить, но ключевой принцип остается неизменным: любой адрес любой страницы, в итоге, должен указывать на экшен, который будет обрабатывать эту страницу.
Есть еще один очень важный компонент ядра движка — Engine. Фактически, все взаимодействие между разными компонентами (вызов модулей, формирование сущностей и проч.) — это все выполняется через Engine.
Вот как можно это представить более схематично:
Здесь Router, Engine, Action, Module, Mapper, Entity — это все компоненты движка.
19 комментариев
http://www.soasta.com/blog/page-bloat-average-web-page-2-mb/
Пилить, строгать, вырезать.
Эххх, такую блогплощадку похерили „усреднениями“
Во-вторых, решил проверить — вот конкретно эта страницы весит около 1 Мб, т.е. аккурат идеал! И это при том, что около 40% — картинки.
Ну, и в третьих, если все ж есть желание стремиться к идеалу — сделайте сперлайт версию шаблона и отдайте ее в публичный доступ, и «к нему на зарастет народная тропа»
Более того, еще в 10 году было ясно, что движок безнадежен: заложенные в него «хитрые» решения типа использования magic methods и конфигов.с.точками были, скажем прямо, дерьмом собачьим. И если раньше они просто замедляли работу, требуя выполнения тысячи лишних операций со строками на каждый запрос, то к моменту, когда началось развитие слабосвязанных архитектур, стало ясно, что без потери совместимости со всеми дополнениями сразу, развивать движок можно только подтыкая в него все новые и новые костыли, что и делалось последние годы. Но ведь для костылей был, есть и будет Вордпресс!
Все достижения php–программирования последних лет — стандартизация автозагрузчиков, модульное тестирование, внедрение зависимостей, composer, миддлвари — прошли мимо. Граф зависимостей стал похож на моток пакли. Банально проверить, не внесли ли новые изменения какую–нибудь регрессию — нельзя. Даже терминология и та невменяемая — что это за «модули», которые жестко связаны с ядром и друг с другом? Что это за «роутер», выполняющий обязанности сразу фронт–контроллера и мидлвари? С каких пор «маппер» стал самостоятельной сущностью, а не незначительной деталью реализации моделей?
Скоро, с релизом ZF3, станет мэйнстримом поддержка diactoros, react-php и других написанных на php веб–серверов, позволяющих не проводить на каждый запрос повторную инициализацию приложений, и это станет последним гвоздем в гроб LS и Alto. За время одного запроса вашего движка, новые веб–приложения успеют отработать пятнадцать. Создавать сообщества на тормозном движке — значит дарить хостерам деньги, а конкурентам — пользователей.
Возможно, вам стоит оставить LS и создать что–нибудь новое? Не можете же вы не видеть, что движок сейчас разработчикам больше мешает, чем помогает?
Вордпресс... Если бы с ним все было так гладко, то мы бы с вами сейчас не разговаривали. Решения для коллективных блогов в нем были ещё до появления Лайвстрита, и даже рабочие, но использовать их было нереально, помните, почему? Потому что каждая новая установка дополнений после 8-10 самых ходовых превращалась в оргию с напильником, а сам сайт — в тормоз и решето.
В общем, я стою на своем: сначала стоит построить прочный универсальный фундамент, а уже на нем воплощать пользовательские мечты. Иначе повторится старая история (как было с phpbb, vbulletin, dle и прочими) — три–четыре года все полны энтузиазма, а потом резко вязнут в болоте обратной совместимости.
И я, честно говоря, даже стал набрасывать текст ответа, полагая, что это такая серьезная концептуальная дискуссия намечается. Но вот второй коммент озадачил: а о чем вообще речь? Так и хочется спросить: «Вы сайтом не ошиблись, уважаемый? Это не Лайвстрит, это — Альто!»
К моменту, когда ЛС достиг версии 0.4, то есть задолго до того как вы его форкнули, все основные проблемы уже были в наличии. Тормозные конфиги? Уже тогда выглядили бредово. Бешеные синглтоны, вызываемые через магические методы? Размазаны по всему коду. Отсутствие автозагрузчика? Ну конечно! Кустарное внедрение зависимостей? Да!
Чем ваш движок 2016 года принципиально отличается от ЛС 2010-го? Помимо появившейся позднее системы ассетов, конечно. Ну да, пользователи оценят админ–панель. Но остальное–то! Тормоза от тысяч вызовов синглтонов через идиотский механизм _CallModule останутся с вами навсегда; без ручного редактирования конфигов все также не обойтись; код разросся и стал совершенно нечитаем (классы длиной в 1500 строк и объемом в полсотни методов?) и невменяем (серьезно, сотни вызовов strtolower на запрос?). Даже представить не могу, почему вы все еще цепляетесь за этот кошмар. За прошедшее время можно было от студента прокачаться до тимлида, а вы воспринимаете всерьез движок на уровне «моя первая цээмэс на похапе».
Чтобы два раза не вставать, про vbulletin, коротко. Когда–то я поддерживал сайт на v3.5.4 — и хотел странного. Ну, энтерпрайзные фичи убрать, колонки в списке тем поменять, добавив к ним вывод кастомных полей, — типичные хотелки, наверняка же кто–то такое уже делал. А вот болт! Чтобы выводить в списке тем кастомные поля, нужно было перехватывать и подменять запрос к базе данных, убрать лишние страницы можно было только редактированием темы и верой в то, что ничего опасного не забыто. С тех пор много думал и пришел к выводу, что типичные модульные системы на основе хуков — полная хрень, потому как их никогда не бывает достаточно, и делать надо сразу с расчетом на замену абсолютнно любого класса ядра.
Вот с чем согласен безоговорочно, так с двумя вещами: с тем, что терминология в ЛС, перетекшая в Альто, мягко говоря, не совсем удачна, и с тем, что граф зависимостей слишком запутан.
Класс конфига, который снаружи, какбэ, выглядит так же, переписывался полностью пару раз и нонче существенно быстрее и гибче — вот тут, конечно, сильно на любителя. Мне лично эта идея с точками-разделителями страшно нравится. На мой взгляд, это чрезвычайно удобная штука. Но за это удобство приходится расплачиваться оверхедом — против этого не попрешь.
А вот насчет внезапного негатива в адрес «магических» методов удивлен. А что, есть нонче серьезные движки на PHP, где «магические» методы не используются совсем? По-моему, эта фича (при некоторых ее недостатках) сегодня одна из наиболее востребованных абсолютно везде. Не, есть, конечно, без «магических» методов, но с декларацией и автогенерацией кода, что, на мой взгляд, гораздо хуже.
Но это ладно, это все лирика. Вопрос в лоб: есть желание делать суперсовременный Альто 2.0, вбухивая в проект время и деньги, года два-три без всякой реальной отдачи? Ок, давайте обсудим концепцию, архитектуру и — вперед. Я поддержу даже такую слегка бредовую идею, как запил движка аж под PHP7. Это неплохой маркетинговый ход будет — первая CMS разработанная сразу под «семерку». Вот только под react работать на текущем этапе я не готов (возможно, в будущем, но не сейчас).
Идет? Но только одно условие — это должна быть серьезная и долгосрочная работа и без всякой анонимности. Если просремся — пусть все знают имена «героев».
Но вот вписываться в крутой вираж, кардинально меняя траекторию движения, я готов только с тем, кто готов за это отвечать, кто согласен разделить не только потенциальный успех, но и возможный провал. А как же иначе-то?
Да и не в этом дело — маркетинга ради можно внедрить все перечисленное хоть в Битрикс, толку-то, если проблемы не решаются? Ну есть у вас автозагрузчик, а зачем он вам, если у вас до сих пор по коду щедро разбросаны include-ы?
Про то, что отдельные классы можно заменить. Буллщит. У вас хренов Router лезет в хренов ModuleViewer. Я как это увидел, немного даже опешил. Копаться в классах такой связности никто кроме вас не рискнет. Особенно при нынешнем уровне покрытия тестами. Нулевом. К тому же сейчас этим никого не удивишь — для подмены классов и существует внедрение зависимостей.
Про магические методы — вы ничего не путаете? Когда CodeIgniter представил «удобный» способ вызова синглтонов через __call(), его всем миром поливали дерьмом, по очевидной причине — с ним зависимости плодятся, как дрожжи в санузле. Кстати, нынешнее положение вашего движка это подтверждает: зависимостей теперь столько, что разгребать их бессмысленно, проще все переписать. И я могу точно сказать, что во всех современных фреймворках использование magic methods сведено к минимуму. В том же Symfony на 30МБ зависимостей их вне тестов определяют раз десять, в основном внутри декораторов и реестров.
На вопрос в лоб: конечно, но не Альто 2.0 и не с Вами. Ничего личного, но у меня уже запланирована разработка своей ЦМС, я уже год в отрыве от работы собираю требования и провожу эксперименты, и абсолютно никакого отношения к коллективным блогам она не имеет. Делать же что–то совместно с людьми, имеющими другие взгляды на программирование — лучший способ всё запороть. И никаких двух–трех лет без всякой отдачи не будет, это безумие. После сбора требований, я просто уйду в Тайгу на полгода и вернусь уже с minimum viable product, завернутым в шкуру медведя. А вы мне предлагаете с незнакомым человеком три года тянуть вола за яйца. Благодарю покорно!
Надеюсь, не станете Вы утверждать, что и в PHP это все используется аж с 94-го года? Будете смеяться, но паттерн «внедрение зависимостей» я использовал еще тогда, когда программировал на машинах СМ-14хх/СМ-13хх, оформляя интерфейсы на Pascal-2, а тело процедур программируя на ассемблере, хоть самого этого модного термина в программировании тогда еще не было (угадайте, когда это было). Но дело-то ведь не в том, что и когда было придумано, мы ведь говорим о CMS на PHP со всеми вытекающими, не правда ли? Ну, вот и давайте об этом и будем.
Слегка офигел. А «щедро» — это сколько в штуках? Вот конкретно сколько инклудов в коде Альто (давайте только не будем считать директиву Смарти «include», ибо это совсем иное, и оставим за рамками сторонние библиотеки)? Вы реально считали или так, лишь бы сказать?
Не путаю ничего ни на грамм. И в CI, и в Yii, и в Symfony они есть. И какая разница, кого чем поливали, если «все леди делают это»? Но вот что «в том же Symfony на 30МБ зависимостей их вне тестов определяют раз десять» — это шок для меня. Десять? Правда? В Yii, если не ошибаюсь, раза два-три. В Альто, если убрать гири совместимости с ЛС — тоже. Так о чем идет речь? Да это о чем угодно, только не про Альто.
А финал ожидаем по сути, но несколько неожиданный по форме:
Во-первых, Вы, по Вашему же признанию, год уже его тянете (ага, « я уже год в отрыве от работы собираю требования и провожу эксперименты»).
Во-вторых, я предлагал-то ровно обратное: я (будучи открытым и невиртуальным) предложил совершенно незнакомому мне анониму работать вместе, рискуя своей репутацией.
Но нет, так нет, буду с нетерпением ждать через полгода из Тайги с Bear CMS :)