Принцип работы Alto CMS в картинках


Каждый запрос, который получает движок, сначала обрабатывается роутером (Router). Примерно так же, как каждого посетителя в крупных компаниях встречает девушка на ресепшен, которая узнает, чего надо посетителю, какой у него вопрос, и затем направляет его к тому нужному менеджеру, так и роутер направляет запрос нужному экшену (Action). Экшен, приняв посетителя запрос, выясняет все подробности, проверяет права и проч., и, выполнив все необходимые формальности, делает запрос в «отдел комплектации» — в компонент модуль (Module). Далее, по запросу из модуля маппер (Mapper) находит и отгружает требуемые сущности (Entity). Модуль, если нужно, может несколько раз получить необходимые данные от маппера, скомпоновать их, как требуется и отдать экшену. Но и экшен может обратиться к разным модулям несколько раз с разными запросами.

Получив все, что нужно, экшен поручает вьюеру (Viewer) доставить результат запроса посетителю сайта в красивой упаковке.

Хоть сам роутер очень программно очень наворочен, его принцип, по сути, довольно прост. Чтоб не писать слишком много букв, вот картинка, которая многое проясняет:

Т.е. нужный экшен по умолчанию определяется по той части URL, которая идет после имени домена. Конечно, есть возможность многое перенастроить и переопределить, но ключевой принцип остается неизменным: любой адрес любой страницы, в итоге, должен указывать на экшен, который будет обрабатывать эту страницу.

Есть еще один очень важный компонент ядра движка — Engine. Фактически, все взаимодействие между разными компонентами (вызов модулей, формирование сущностей и проч.) — это все выполняется через Engine.

Вот как можно это представить более схематично:

Здесь Router, Engine, Action, Module, Mapper, Entity — это все компоненты движка.

Похожие статьи

  • Реализация парадигмы MVC в AltoCMS
    MVC – это, как известно, Model-Viewer-Controller. В разных фреймворках и в разных CMS она реализуется по своему. И в AltoCMS ее реализация имеет свои особенности.
  • Компонент Entity (Сущность)
    Сущность – это некий набор данных, которые называют «свойствами» (property). Например, сущность «Пользователь» (User) имеет такие свойства, как идентификатор, логин, адрес электронной почты, и т.д.
  • Замена ЛСовскому Config::Set('router.page........')
    Здравсвуйте открыл свежую из гита версию Альто и возник вопрос по плагинам как сделать замена ЛСовскому Config::Set('router.page........') Смотрел плагин estheme нашел вот такую интересную строчку: /** *...
  • Переименование blogs в community и blog в id
    Всем привет еще раз. Прошлый топик я убрал в черновики, потому что сам уже что-то намудрил с конфигом и запутался с тем, в чем же была проблема. Тем не менее сейчас, когда я разобрался как нужно прописывать роуты,...

19 комментариев

0
А есть более подробное описание, в виде инструкции или руководства? Было бы ваще супер если есть с примерами
0
Как уменьшить вес страницы? 2 мегабайта это злостность...
0
Это не «злостность», а средний вес страницы в инете по состоянию на май 2015 года:

http://www.soasta.com/blog/page-bloat-average-web-page-2-mb/
0
Блоггеры существа особенные многие с мобильников в картонных коробках бложат. « мегабайта это не просто злостность, а „не простительное зло“ В идеале вес страницы не должен превышать 1 мегабайт. Теперь придётся оптимизировать код.
Пилить, строгать, вырезать.
Эххх, такую блогплощадку похерили „усреднениями“
0
Во-первых, идеал — вещь сугубо субъективная. Тем более, раз «идеал» в два раза отстает от нынешних средних значений.

Во-вторых, решил проверить — вот конкретно эта страницы весит около 1 Мб, т.е. аккурат идеал! И это при том, что около 40% — картинки.

Ну, и в третьих, если все ж есть желание стремиться к идеалу — сделайте сперлайт версию шаблона и отдайте ее в публичный доступ, и «к нему на зарастет народная тропа»
0
Вадим, понимаю, что вам неприятно это читать, но сейчас, в 2016 году, нет ни единой причины вкладывать время в разработку на LS и его форках. Единственное, на что он сейчас годится — служить наглядным пособием по последствиям ошибок развития сообществ и проектирования приложений.

Более того, еще в 10 году было ясно, что движок безнадежен: заложенные в него «хитрые» решения типа использования magic methods и конфигов.с.точками были, скажем прямо, дерьмом собачьим. И если раньше они просто замедляли работу, требуя выполнения тысячи лишних операций со строками на каждый запрос, то к моменту, когда началось развитие слабосвязанных архитектур, стало ясно, что без потери совместимости со всеми дополнениями сразу, развивать движок можно только подтыкая в него все новые и новые костыли, что и делалось последние годы. Но ведь для костылей был, есть и будет Вордпресс!

Все достижения php–программирования последних лет — стандартизация автозагрузчиков, модульное тестирование, внедрение зависимостей, composer, миддлвари — прошли мимо. Граф зависимостей стал похож на моток пакли. Банально проверить, не внесли ли новые изменения какую–нибудь регрессию — нельзя. Даже терминология и та невменяемая — что это за «модули», которые жестко связаны с ядром и друг с другом? Что это за «роутер», выполняющий обязанности сразу фронт–контроллера и мидлвари? С каких пор «маппер» стал самостоятельной сущностью, а не незначительной деталью реализации моделей?

Скоро, с релизом ZF3, станет мэйнстримом поддержка diactoros, react-php и других написанных на php веб–серверов, позволяющих не проводить на каждый запрос повторную инициализацию приложений, и это станет последним гвоздем в гроб LS и Alto. За время одного запроса вашего движка, новые веб–приложения успеют отработать пятнадцать. Создавать сообщества на тормозном движке — значит дарить хостерам деньги, а конкурентам — пользователей.

Возможно, вам стоит оставить LS и создать что–нибудь новое? Не можете же вы не видеть, что движок сейчас разработчикам больше мешает, чем помогает?
0
react-php конечно интересная штука, и очень практичная, но... когдато про web-dav говорили что с его приходом эпоха ftp серверов умерла. Но видимо что-то пошло не так. Новые вещи появляются часто. Я бы сказал, что нужно подумать об адаптации этих вещей к существующему проекту. Возможно что после нескольких адаптаций от исходного проекта останется только название, но зато это произойдет постепенно.
+1
В целом вашу мысль поддерживаю и проблем там over дохрена, и я лично считаю что ветка альто >= 1.1 обречена. Но на мой взгляд причина не в этих программерских изъебствах, которые обычному пользователю абсолютно не впились. Есть более фундаментальная проблема, что движок не желает банально решать проблемы которые стоят перед вебмастерами, а разработчики их не слышат вообще. Полностью отсутствует обратная связь, а ресурсов и мотивации не хватает даже на то чтобы закрывать сотни багов, отвечая в духе «доктор: ну не знаю у меня такая же нога и ничего не болит». Вордпресс прекрасно доказал что блин, не тратьте время на продукт для разработчиков, тратьте время на продукт для ПОЛЬЗОВАТЕЛЕЙ. А то что вы говорите по сути, если перевести на русский — давайте в бетонную стену не головой биться и супер навороченным электронным микроскопом.
0
не тратьте время на продукт для разработчиков, тратьте время на продукт для ПОЛЬЗОВАТЕЛЕЙ
совершенно так :) Никто не спорит, а даже наоборот.
0
Да я бы и рад делать продукт для пользователей, да не выходит каменный цветок: если взять надстройку уже существующих страниц, то вещи, делающиеся в Вордпрессе за час, Лайвстрит растянет на унизительные восемь, просто потому что написание кода превращается в наркоманский трип, в ходе которого в голову разработчика перекочует полдюжины модулей и два десятка классов ядра. Я иногда читаю ваши посты — вы спрашиваете «что», «где», «как». Вам, как мне кажется, просто стесняются дать честный ответ — хрен его знает! Игнорируя сложившиеся практики программирования и позволив его коду обрастать зависимостями, авторы движка добились полной его непознаваемости. Его код — хренов Гордиев узел. Поэтому странно читать, что разработчики вас не слышат. Потому что разработчиков — 3,5 калеки, они заняты не доработкой движка, а борьбой с ним.

Вордпресс... Если бы с ним все было так гладко, то мы бы с вами сейчас не разговаривали. Решения для коллективных блогов в нем были ещё до появления Лайвстрита, и даже рабочие, но использовать их было нереально, помните, почему? Потому что каждая новая установка дополнений после 8-10 самых ходовых превращалась в оргию с напильником, а сам сайт — в тормоз и решето.

В общем, я стою на своем: сначала стоит построить прочный универсальный фундамент, а уже на нем воплощать пользовательские мечты. Иначе повторится старая история (как было с phpbb, vbulletin, dle и прочими) — три–четыре года все полны энтузиазма, а потом резко вязнут в болоте обратной совместимости.
0
А что не так с vbulletin, кроме того что он платный?
0
День начался с замечательно комментария. Нет, правда, я нисколько не иронизирую — первый коммент мне очень понравился, хоть и а) сам не знаю почему; б) я с ним не согласен по многим тезисам.

И я, честно говоря, даже стал набрасывать текст ответа, полагая, что это такая серьезная концептуальная дискуссия намечается. Но вот второй коммент озадачил: а о чем вообще речь? Так и хочется спросить: «Вы сайтом не ошиблись, уважаемый? Это не Лайвстрит, это — Альто!»
0
В контексте поднятой мною темы различия между Альто и ЛС совершенно несущественны.

К моменту, когда ЛС достиг версии 0.4, то есть задолго до того как вы его форкнули, все основные проблемы уже были в наличии. Тормозные конфиги? Уже тогда выглядили бредово. Бешеные синглтоны, вызываемые через магические методы? Размазаны по всему коду. Отсутствие автозагрузчика? Ну конечно! Кустарное внедрение зависимостей? Да!

Чем ваш движок 2016 года принципиально отличается от ЛС 2010-го? Помимо появившейся позднее системы ассетов, конечно. Ну да, пользователи оценят админ–панель. Но остальное–то! Тормоза от тысяч вызовов синглтонов через идиотский механизм _CallModule останутся с вами навсегда; без ручного редактирования конфигов все также не обойтись; код разросся и стал совершенно нечитаем (классы длиной в 1500 строк и объемом в полсотни методов?) и невменяем (серьезно, сотни вызовов strtolower на запрос?). Даже представить не могу, почему вы все еще цепляетесь за этот кошмар. За прошедшее время можно было от студента прокачаться до тимлида, а вы воспринимаете всерьез движок на уровне «моя первая цээмэс на похапе».

Чтобы два раза не вставать, про vbulletin, коротко. Когда–то я поддерживал сайт на v3.5.4 — и хотел странного. Ну, энтерпрайзные фичи убрать, колонки в списке тем поменять, добавив к ним вывод кастомных полей, — типичные хотелки, наверняка же кто–то такое уже делал. А вот болт! Чтобы выводить в списке тем кастомные поля, нужно было перехватывать и подменять запрос к базе данных, убрать лишние страницы можно было только редактированием темы и верой в то, что ничего опасного не забыто. С тех пор много думал и пришел к выводу, что типичные модульные системы на основе хуков — полная хрень, потому как их никогда не бывает достаточно, и делать надо сразу с расчетом на замену абсолютнно любого класса ядра.
+2
Не, ну конечно, если не знать, что в Альто используются такие штуки (или как там выше было сказано — «достижения php–программирования последних лет»), как обсерверы, декораторы, автозагрузка psr0 и psr4, то да, как бы все так же. И то, что классы ядра, включая Engine и Router можно заменить — это тоже мало кто знает, в чем, не спорю, моя вина, ибо внятной документации нет до сих пор. Всего этого и духу не было в ЛС 1.0.х (за ЛС 2.0 особо не слежу). А вот _CallModule, кстати, в нынешнем коде живет исключительно как дань совместимости, но ему осталось жить не так уж и долго.

Вот с чем согласен безоговорочно, так с двумя вещами: с тем, что терминология в ЛС, перетекшая в Альто, мягко говоря, не совсем удачна, и с тем, что граф зависимостей слишком запутан.

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

А вот насчет внезапного негатива в адрес «магических» методов удивлен. А что, есть нонче серьезные движки на PHP, где «магические» методы не используются совсем? По-моему, эта фича (при некоторых ее недостатках) сегодня одна из наиболее востребованных абсолютно везде. Не, есть, конечно, без «магических» методов, но с декларацией и автогенерацией кода, что, на мой взгляд, гораздо хуже.

Но это ладно, это все лирика. Вопрос в лоб: есть желание делать суперсовременный Альто 2.0, вбухивая в проект время и деньги, года два-три без всякой реальной отдачи? Ок, давайте обсудим концепцию, архитектуру и — вперед. Я поддержу даже такую слегка бредовую идею, как запил движка аж под PHP7. Это неплохой маркетинговый ход будет — первая CMS разработанная сразу под «семерку». Вот только под react работать на текущем этапе я не готов (возможно, в будущем, но не сейчас).

Идет? Но только одно условие — это должна быть серьезная и долгосрочная работа и без всякой анонимности. Если просремся — пусть все знают имена «героев».
0
Но только одно условие — это должна быть серьезная и долгосрочная работа и без всякой анонимности. Если просремся — пусть все знают имена «героев»
Это не индивидуальное предложение? Оно ведь всем адресовано ? :)
Отредактирован:
+1
Я бы так сказал: участвовать в разработке Альто, что-то предлагать, выдавать пуллреквесты на гитхабе могут и сейчас все желающие и вообще без всяких условий.

Но вот вписываться в крутой вираж, кардинально меняя траекторию движения, я готов только с тем, кто готов за это отвечать, кто согласен разделить не только потенциальный успех, но и возможный провал. А как же иначе-то?
-1
Вадим, про такие штуки, как обсерверы и декораторы, я читал ещё в первой половине нулевых в известной вам книге 94 года выпуска. Немного опоздали гордиться подобными новшествами :)

Да и не в этом дело — маркетинга ради можно внедрить все перечисленное хоть в Битрикс, толку-то, если проблемы не решаются? Ну есть у вас автозагрузчик, а зачем он вам, если у вас до сих пор по коду щедро разбросаны include-ы?

Про то, что отдельные классы можно заменить. Буллщит. У вас хренов Router лезет в хренов ModuleViewer. Я как это увидел, немного даже опешил. Копаться в классах такой связности никто кроме вас не рискнет. Особенно при нынешнем уровне покрытия тестами. Нулевом. К тому же сейчас этим никого не удивишь — для подмены классов и существует внедрение зависимостей.

Про магические методы — вы ничего не путаете? Когда CodeIgniter представил «удобный» способ вызова синглтонов через __call(), его всем миром поливали дерьмом, по очевидной причине — с ним зависимости плодятся, как дрожжи в санузле. Кстати, нынешнее положение вашего движка это подтверждает: зависимостей теперь столько, что разгребать их бессмысленно, проще все переписать. И я могу точно сказать, что во всех современных фреймворках использование magic methods сведено к минимуму. В том же Symfony на 30МБ зависимостей их вне тестов определяют раз десять, в основном внутри декораторов и реестров.

На вопрос в лоб: конечно, но не Альто 2.0 и не с Вами. Ничего личного, но у меня уже запланирована разработка своей ЦМС, я уже год в отрыве от работы собираю требования и провожу эксперименты, и абсолютно никакого отношения к коллективным блогам она не имеет. Делать же что–то совместно с людьми, имеющими другие взгляды на программирование — лучший способ всё запороть. И никаких двух–трех лет без всякой отдачи не будет, это безумие. После сбора требований, я просто уйду в Тайгу на полгода и вернусь уже с minimum viable product, завернутым в шкуру медведя. А вы мне предлагаете с незнакомым человеком три года тянуть вола за яйца. Благодарю покорно!
+2
Эх, как красиво все начиналось, и как банально заканчивается. :( Все ж есть очень большие сомнения, что Вы хотя бы изучили движок, прежде чем говорить о нем (ну, хотя бы для того, чтоб лучше понять для себя, как делать не надо).

...я читал ещё в первой половине нулевых в известной вам книге 94 года выпуска
Надеюсь, не станете Вы утверждать, что и в PHP это все используется аж с 94-го года? Будете смеяться, но паттерн «внедрение зависимостей» я использовал еще тогда, когда программировал на машинах СМ-14хх/СМ-13хх, оформляя интерфейсы на Pascal-2, а тело процедур программируя на ассемблере, хоть самого этого модного термина в программировании тогда еще не было (угадайте, когда это было). Но дело-то ведь не в том, что и когда было придумано, мы ведь говорим о CMS на PHP со всеми вытекающими, не правда ли? Ну, вот и давайте об этом и будем.

...до сих пор по коду щедро разбросаны include-ы?
Слегка офигел. А «щедро» — это сколько в штуках? Вот конкретно сколько инклудов в коде Альто (давайте только не будем считать директиву Смарти «include», ибо это совсем иное, и оставим за рамками сторонние библиотеки)? Вы реально считали или так, лишь бы сказать?

Про магические методы — вы ничего не путаете?
Не путаю ничего ни на грамм. И в CI, и в Yii, и в Symfony они есть. И какая разница, кого чем поливали, если «все леди делают это»? Но вот что «в том же Symfony на 30МБ зависимостей их вне тестов определяют раз десять» — это шок для меня. Десять? Правда? В Yii, если не ошибаюсь, раза два-три. В Альто, если убрать гири совместимости с ЛС — тоже. Так о чем идет речь? Да это о чем угодно, только не про Альто.

А финал ожидаем по сути, но несколько неожиданный по форме:
А вы мне предлагаете с незнакомым человеком три года тянуть вола за яйца
Во-первых, Вы, по Вашему же признанию, год уже его тянете (ага, « я уже год в отрыве от работы собираю требования и провожу эксперименты»).

Во-вторых, я предлагал-то ровно обратное: я (будучи открытым и невиртуальным) предложил совершенно незнакомому мне анониму работать вместе, рискуя своей репутацией.

Но нет, так нет, буду с нетерпением ждать через полгода из Тайги с Bear CMS :)
0
Стоило бы немного подробней об этом написать или дать ссылку на источник.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.