Работа над "билдом" muonline

...идет полным ходом, но... в основном, по выходным.

Что уже сделано:

• подобран диз (название на одном известном форуме у темы espada-legend, но сам диз сделан для thanatos'a)
• все элементы диза разбиты по плагинам
• сделаны плагины авторизации, серверов(qinfo), меню
• модули: новости, показ ошибок 

Скорее всего, сначала сделаю упрощенную версию и выложу ее. далее посмотрим, как пойдет.

Как плагин превращается в меню

как оно это все.. ну там... внутри (о фитчах)

Шаблонизатор

При генерации страницы (ф-я out) так же из папок темы css и js "подтягиваются" скрипты с названием папки, то есть, если вызвать out("main","news"), которая "кушает" шаблон main.html из папки news, то при генерации html-кода будут проверены на существование файлы:
theme/название_темы/js/news.js и theme/название_темы/css/news.css.

Если они существуют, то их содержимое будет помещено в |global_js| и |global_css| в index.html темы. Так же учитываются и плагины. То есть, весь код или стили будут в 1 месте, а не подгружаться вместе с каждым шаблоном.

О кешировании

Теперь в контроллере есть возможность кешировать (визуальные) результаты работы любых  методов класса, либо по названию метода, либо задавая свои собственные названия

О плагинах

Плагины теперь тоже имеют права доступа для групп, что дает дополнительную гибкость и использования оных для постоений меню и прочих "фишек" для отдельно взятых групп.

О меню

• В меню вновь вернулась возможность управлять порядком позиций (через админку, естественно). 
• Идеологически, все меню рекомендуется реализовывать в плагинах. 1 плагин отвечает за 1(?) меню.

Первое видео MWCE 1.6.2 - альфа-версия.

Накатил ролик, чтобы вы могли посмотреть на то, о чем я столько написал (и не лень же было).


Вкратце пробегусь, что на видео:
С самого начала, я показываю установку: возможные типы подключений (кстати, расширяемо + намек, что это может быть не обязательно только ms sql), адрес до сервера с бд и авторизационными данными.
Далее, вид админки (цифры, что слева на фоне авторизации - генерация. чуть врет, зараза, можно не обращать внимание):
- авторизация
- кратенький "пробег" по основным модулям.

Внимание обращу на то, что время от времени я выбираю "билд" и вот для чего: так как, я уже упоминал в прошлых записях, что "билды" имеют независимые настройки, нужно переключаться между админкой и нужным "билдом", чтобы настроить конфиги, "запилить" плагины или страницы, другого способа как сделать универсальней я, к сожалению, не придумал.
Да, еще упомяну об одной вещи: для каждой базы данных админка будет своя. То есть, для каждой базы пара - сайт(может быть не 1) + админка. Усложнять, пока не вижу смысла

как оно это все.. ну там... внутри (о шаблонизаторе)

В данной статье речь пойдет о шаблонизаторе и, наверное, наиболее интересной эта тема покажется дизайнерам и девелоперам.

Начну с того, что было раньше. Для новичков - в MWC есть свой шаблонизатор (угу, он же view). Это не smarty или иной известный продукт, а самописный ... класс, основная идея которого была вычерпнута из интернетов - "резервируем" слова и заменяем их на словарик. Как это работает внутри сейчас смысла рассказывать не вижу, а вот что изменилось со старых версий рассказать стоит. На данный момент, скелет темы выглядит так:

theme - общая папка тем, admin - тема админки, внутри много папок, одна из которых html. Все папки в html  кроме public содержат шаблоны к определенным скриптам (по названию папок), в public лежат шаблоны главной страницы, страницы логина и ряда плагинов, где по 1 шаблону на "брата". Кстати, images, js,scripts,css отведены под "особенные" скрипты или ксс файлы, которые используются только в данной теме. Суммируя увиденное - я упорядочил файлы и скомпоновал их по смысловой и служебной нагрузке, а то вот такое несколько неудобно:

Возможно, перфекционизм со мной сыграл злую шутку, но мне вот так лично мне нравится больше:

Это несколько изменило функции, которые отвечали за "показ на экран", теперь туда в некоторых случаях нужно будет указывать папку, в которой находится тот или иной шаблон.

Так же были пересмотрены функции, которые добивали словари, в общем, из такого вот безобразия получилось другое безобразие :) :

На этом, думаю надо заканчивать повествование... да, кстати, сейчас полным ходом доделываю инсталку для админки (сопсно, ядра), потом пишу немного howto, а потом скорее всего beta версия будет в свободном доступе.

очередная alpha muwebclone engine

Вместо введения.

Добил, наконец-то, до альфа версии обновленный движок. Ну, точнее как, добил я его гораздо раньше, админку долго и усиленно выпиливал и допиливал. Многое убрал, многое пересмотрел, с учетом опыта пользования:

Вот так теперь выглядит меню админки. Кто пользовался предыдущей версией увидит, что названия страниц были изменены на более простые и добавился плагин, что показывает билд, но о нем позднее.

Итак, суммарно и доходчиво, что же нового будет в данной версии и чем она отличается от предыдущих.

Самое первое, на что хочется обратить внимание: наконец-то есть полноценная работа с MVC, но изначально, когда сей велосипед [движок] был изобретен, он позиционировался, как наиболее простой и быстрый в разработке и добавлении своих модулей. А чтобы писать применяя MVC, все же, нужно изучать движок и знать некоторые особенности, а это долго и порог вхождения явно выше, чем просто функциональное программирование.
Поэтому я долгое время не хотел уходить от модели "почти MVC". Движок давал песочницу и ряд инструментов-игрушек, чтобы можно было "играть" в ней. Но в силу того, что я использую MWC еще и в enterprise, я "уперся в потолок" возможностей старой версии. И, волей не волей, мне пришлось думать, как увеличить себе высоту потолка, чтобы не упираться, но в то же время совсем убегать от старых наработок не хотелось, так как накидать функционально модуль с надписью "привет мир!" куда быстрее, чем городить шаблон, писать модель и управлять контроллером... в общем, меня посетила мысль.. точнее 2: 1 - а зачем отказываться; 2 - почему бы не совместить. И действительно, в данной версии, 1.6.2 можно писать и с идеологией MVC и обычным функциональным программированием и не париться ни о каких классах.

Идеология.

Движок стал похож на фрейморк(набор инструментов) по структуре(да и не только по структуре).
В корне находится 6 папок и пара-тройка файлов:

Папка app содержит в себе родительские классы контроллера, модели, шаблонизатора и ряда вспомогательных классов. В папке configs можно найти файл с настройками самого ядра, libraries содержит сторонние библиотеки, например, phpexcel. Некоторые логи хранятся в текстовом виде в папке log, а в theme хранятся, очевидно, темы. 

Самая интересная папка - build, в ней хранятся, сами "сайты". Админ-панель тоже является отдельным "сайтом" и вот так выглядит ее структура папок (равно как и для любых сайтов в папке build, дефолтная структура буде именно такой):

Структура папок сильно напоминает ту, что была в предыдущей версии, единственная разница лишь в том, что вместо "pages" теперь "controllers" и "models" (к слову, названия можно менять как душе угодно), в которых, соответственно, находятся контроллеры и модели. Каждый билд рассматривается как отдельная сущность со своими конфигурациями. 

Что дает такой подход:

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

про удобство и настройки рассказывать не буду. кто пользовался - знает.

    

Распространение.

Само ядро будет совершенно бесплатно. + к нему будет приложен пример работы. Ряд "билдов" под определенные направления тоже будет выложен совершенно бесплатно.

В чем моя выгода.

Примерно, с версии 1.4 я хотел сделать платформу для разработки сайтов. Тогда тематика была узкая - Muonline. С течением лет мои потребности, как и взгляды менялись (думаю, это нормально :) ), по развитию самого движка это можно проследить.
Так вот, цель была создать платформу - на данный момент считаю, что я близок. Чем она выгодно отличается от того что уже есть, имею ввиду симфонии, уии и т.п. ? Да, наверно, ничем. MWC был(да и есть) хобби, результаты которого я использую и на работе тоже.
Ну и понятно, что ежели вдруг найдутся те люди, кому надо будет напилить сайтик и обратятся ко мне, у меня есть готовый инструмент. Удобно? я считаю да.

как оно это все.. ну там... внутри (о плагинах)

Вообще, лучше начал измышления с определения:

Плаги́н (англ. plug-in, от plug in «подключать») — независимо компилируемый программный модуль, динамически подключаемый к основной программе и предназначенный для расширения и/или использования её возможностей. Плагины обычно выполняются в виде библиотек общего пользования. (https://ru.wikipedia.org/wiki/Плагин попутно замечу что геолокация ru.wiki аж в далеких сша, по сему стоит относится ко всем материалам несколько с сомнением) 

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

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

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

единственное, чем. пожалуй, пока ограничу плагины - у них не будет бегрануда (он просто им не нужен, во-вервых, а, во-вторых, если их оставить, то каждый модуль помимо своей работы будет выпиливать еще и работу плагинов, а оно нам надо?).

как оно это все.. ну там... внутри

Сия запись - рассуждение, анализ уже содеянного, для тех, кто, возможно, пойдет тем же путем. Речь пойдет о новой версии MWCe, та, что с именованием 1.6.2.

Итак, первое, с чем мне пришлось столкнуться при переходе с недо-mvc, на mvc - что делать с плагинами: в старом варианте они выполнялись чуть раньше генерации страниц. По факту плагины - почти те же страницы, просто они выполняются при любом вызове любых страниц, так как они составляют часть интерфейса, а фактически, на них возложена мелкая, но очень нужная логика: отображение определенных менюшек для определенных групп пользователей или банальный логин и т.д.

В текущем же случае, получалось несколько странно: либо вписывать их в головной Controller, чтобы при каждом обращении к очередной странице оно все генерировалось и не надо было бы заботится о том чтобы вписывать их каждый раз, но большое "но" заключалось в том, что это "почти" страницы, да и как быть с ajax запросами к страницам, тоже генерировать плагины, что там и не нужны?..  В общем, даже если я их и вписываю в контроллер, то остается вопрос с использованием MVC в плагинах, так как если уж писать  как положено, так сразу, а не "потом допилю" - нет ничего более постоянного, чем временное.
Делать нечего - напилил PController специально для плагинов, отличие от страниц в том, что в плагине точка входа только одна, потому что, в любом случае, вызывать экшены как-то не нужно (ну, по крайней мере, в моем видении), хотя при желании можно сделать ajax запросы и достичь нужного функционала.
На самом деле, вышло совсем не плохо: получилось так, что на уровне плагина можно при определенных обстоятельствах изменить страничку без перезагрузки, так как плагин запускаются гораздо раньше (банальная подмена get-параметра страницы усе решила), чем генерация страничек и вообще их логика, что очень удобно при сокрытии страниц от определенных пользователей или  при выведении логин-формы. Свои велосипеды я пока выкладывать не буду, но придет время - все можно будет скачать и посмотреть на мой кривой код и лайв-примеры.
Единственное, что меня беспокоит - для каждого плагина по факту инициализируется 2 класса: контроллер и модель, коннект к бд проходит чуть пораньше и всего 1 раз, так как иначе создавать подключение для каждого плагина (коих может быть сколь угодно) + еще страница было бы подобно выстрелу себе в ногу и расстрелу сервера баз данных, по понятным причинам. Тык вот, время генерации и потребляемые ресурсы. сейчас пока пишу админку, так сказать - сердце самого движка (если мозг - контроллеры и модели) смотрю и стараюсь воевать за каждую сотую долю времени генерации...

В процессе.... как же тяжко переходить опять в MVC, зато столько ништяков...

Немного о старом и еще чуть-чуть о новом MuWebClone и о его развитии

Я как-то подзабросил блог. Надо бы чуть-чуть его подраззабросить.

***

Сопсно, речь поведу о новом mwce, шо будет нового и как оно примерно будет работать. Пока это мысли-наработки, частично даже  реализованные.
Итак, прежде чем говорить о версии 1.6.2, вспомним, а что было до... Хотя, скорее для себя я вспомню :).
Сначала было слово... ну, это понятно.
Первый страшный mwc был создан на основе тогда знаменитого muweb. Причем, создан - громко сказано, выглядело это "я слепила из того что было", даже хуже.
Потом "проект" был заброшен, но идея жила, а автор усиленно (когда не мешала лень) пытался выпрямить руки.
Потом появился  уже mwc, как оформившийся сайт с какими-то плюшками от 0.1 до 1.4, потом был 1.5 с шаблонзатором и говнокодом, но уровень хелоувордщика преодолен не был.
Потом было решено сделать 1.6, его можно считать попыткой ребетенка сделать первые щаги.
Сделал. Принцип его был "почти MVC": как таковой mvc используется только в недрах сайта, все остальное заточено под простое функциональное программирование с небольшими вкраплениями классов, так сказать, для простого хелоувордщика, да...
Так вот, так как некоторая основа используется в энтерпрайзе (для интрасети  и не совсем в виде системы управления проектами), я понял, что местами я уперся в потолок возможностей того "творения", что было запилено + постоянная халтурка с напилом модулей всем тем, кто в свое время обзавелся 1.6 двиглом:
сайты сами по себе несколько отличались: у одного было отличие в шаблонизаторе, у второго куча баз, у третьего еще что-то там...

Ну, в общем для тех, кто хоть раз занимался паттерном mvc сейчас уже ухмыляется: мол, да, ты описываешь преимущества как раз-таки обычного model-view-controller паттерна.

Так как я особо не парился в свое время с шаблонами программирования, то и использовал их не ахти как активно (даже сейчас считаю, что лучше недобдеть чем перебдеть, в данном случае, ибо если шаблоны использовать там, где они на фиг не нужны, то кроме захламления кода ничего хорошего не получится), то сел штудировать книги, статьи, код. Ну и, в конце концов, насмотревшись творений умных дядь типа yii и симфоний, я пришел к выводу, что, пожалуй,  стоит "убрать" ограничение "онли простой подход", и на свет в муках начала вырисовываться 1.6.2 (1.6.1 все тот же 1.6, только со своеобразным "сервис паком").

Концепция нового 1.6.2 будет примерно в следующем:
- есть основа с классами-родителями: контроллера, модели, ряда вспомогательных классов, сторонних библиотек
- есть билды (привет, bundle), унаследованные от данных родителей, со своими направлениями расширения.
Это автоматически помогает мне в 1 месте держать хоть все проекты кастумеров и допиливать их в нужном направлении, причем, при выявлении более удачного подхода для решения какой-либо задачи я могу путем изменения родителя запилить для всех проектов сразу очередной патчик (или для каждого в отдельности, если это не касается ядра), то есть по факту управление уровнем абстракции. Лично мне нравится такая идея :) Ваш Кэп.
- есть поддержка плагинов.
а куда без них? попробовав раз - торчу и сейчас.
- есть возможность писать и обычные функциональные скрипты как это было во всех предыдущих версиях. Это значит, что до сих пор, кому-то не нужно будет затачиваться на тему, как работает все это внутри и как писать свои контроллеры, модели и шаблоны. То есть, я не отказался от гибридного подхода, а все также его продвигаю. Стрелять по воробьям из такнка - это весело и даже иногда действенно, но требует затрат времени, которое, как обычно, еще вчера закончилось. Это, конечно, навалило ряд вопросов, как это все заставить работать... вроде как разрулил, на тестах посмотрим, был я прав или не очень.  Ваш Кэп.

Потом я подумал, что иметь конечно кастумеров - круто, но все-таки изначально, в саамом начале пути mwc, ставшего аж mwce была цель сделать лвиг для всех, а не только для тех, кто готов платить. Поэтому сам "движок" будет свободным и доступен для скачивания, возможно, сделаю репозиторий на том же гите, пока не решил. А вот билды уже буду писать или дорабатывать под конкретные нужды людей, будь то просто сайт-визитка или же muonline проект, а может даже ла проект, не знаю, время и востребованность очередного велосипеда покажет, нужно ли оно или нет.
Да и чего греха таить, хочешь найти ошибки и усовершенствовать то, что есть наиболее быстрым способом? Выложи в паблик! Ну "тыпонел" да? Ваш Кэп.

За сим пока откланиваюсь, ежели будет еще что интересного - отпишу.

P.S.:Если кому-то интересно, как организовывалась система управления проектами или как я доходил до понимания, что ж такое этот мэ вэ цэ, то пишите, напишу статейки еще. 

1.6.2 быть.
и быть free

После отпуска

Как-то несколько лениво втягивается все после отпуска :) На работе ожидается много интересных задач, прям-таки, пребываю в нетерпении оных. + надо совершить победный рывок для mwc 1.6 и потихоньку реинкарнировать и отрефакторить mwc 1.5. Как - то пора уже поставить точку, а то пока многоточие..