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

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

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

При генерации страницы (ф-я 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, зато столько ништяков...