Wrong MVC - система для быстрой web разработки и запуска сайтов

Доброго времени суток коллеги!
Приглашаю тестировать, использовать, оставлять комментарии, идеи, пожелания. Качественный open source проект сделанный с любовью!

Wrong MVC - это среда для WEB разработки, включающая в себя множество необходимых компонентов, систематизированных в единое пространство и иерархию. Это тот фундамент, позволяющий очень гибко создавать уникальные системы с функционалом действий и страниц, назначенным определенным группам пользователей. Это система для создания на её базе любых WEB проектов, от простейших лендингов в несколько страниц, до сложнейших с многоуровневым разграничением прав доступов и пользовательского функционала, групповыми политиками доступов к моделям функционала, готовым умным uri роутингом, собственной cron реализацией, визуализацией всех моделей и их удобным управлением.

Это не Laravel в плане концепции MVC как таковых, и это не Wordpress в плане концепции сайтовых движков, это WRONG MVC! Система рассчитана на использование опытными Full-stack разработчиками, здесь реализованы все базовые нюансы, которые существенно упрощают и систематизируют разработку. Разобравшись в логике работы данной системы и её возможностях, вы гарантированно и навсегда забудете про php фреймворки или движки! Потому что сборка и реализация любых сложных проектов превратится в простое удовольствие.

ПО "Wrong MVC" имеет открытый исходный код и распространяется под лицензией свободного ПО - Apache License 2.0.

https://wrong-mvc.com/ - сайт проекта, с подробной документацией и описанием
https://github.com/avtobys/wrong-mvc - проект на гитхаб
https://gitlab.com/avtobys/wrong-mvc - проект на гитлаб

Из того что "под капотом":
- Визуально понятная система моделей и контроллеров
- Неограниченная вложенность уровней доступа
- Автоматический роутинг страниц и запросов
- Настраиваемые шаблоны страниц и действий
- Конструктор триггеров действий
- Встроенный редактор кода с подсветкой и горячими клавишами
- Управление группами доступа, пользователями и их функционалом
- Умные стеки PHP - JavaScript кода
- Модальные окна запрашиваемые автоматически из API по AJAX
- Умная подгрузка js библиотек по мере их применения
- API действий, выборок и модальных окон
- X-Auth-Token авторизация в API
- Копирование, экспорт, импорт моделей
- Логгирование любых действий
- Встроенные CRON задачи с выполнением от имени пользователей
- Готовый gulp комбайн для вёрсток и кастомизации
- Создание простых сайтов в пару кликов из готовых шаблонов
- Автоматическая защита всех форм от CSRF
- Бессрочная авторизация по COOKIE с криптованием UID
- Hcaptcha по лимиту Brute force попыток
- Oauth google + yandex авторизации
- Backend: PDO MySQL + PHP
- Frontend: Bootstrap v4.6.1 + JQuery
- Установка в пару кликов

3

Сообщение от avtobys тут ещё и терминал встроенный в будущем поставить планируется, чтобы далеко не бегать к нему

Ну тут не известно понадобиться. Я делал для битрикс модуль изначально это как раз был полноценная консоль, потом оставил только для работы с git. В итоге практически не пользуюсь. исключение когда есть какие то проблемы с настройкой ssh, и с git надо что то выполнить - что крайне редко. Модуль бесплатный и на маркете, пользуются, но о расширении функционала заявок нет

тут надо еще понимать, что на грамотном проекте на бою на прямую ни кто ни когда файлы не правит. Я, например, как раз наоборот админкой практически не пользуюсь. Из таких дев задач, единственное что использую это консоль SQL команд. (лень пароли к базам на всех проектах запоминать)

0

Сообщение от voral тут не известно понадобиться.

Да это такое, в любом случае это уже будет после docker-compose сборки консоль, там буду встраивать скорее всего, это не скоро ещё. Хочу разворачивать её в будущем сразу с готовым http и бд в докере, чтобы всё как положено, со всеми настроечками, ничего никуда не лепить. Какой нить из isp manager можно взять, вроде сойдет терминал халявный. А там гляну, может что то и урезанное.

0

все же стоит продумать как обновляться. Я сейчас чтоб обновиться отменил все изменения. И теперь надо будет восстанавливать. конечно это все "делается". Но если речь о боевом сервере, то придется его на время обновлений закрывать.

По крайней мере в первую очередь сделайте поддержку .dev.local и сами добавьте этот файл в .gitignore. в общем надо продумать как иметь файлы проекта пользователя от файлов вашей среды разработки.

Так же, а как изменения в БД производятся при обновлении? (если нет можно пока посмотреть на phinx)

Добавлено через 30 минут
Кстати, после обновления сайт не открывается. В логах
Добавлено через 2 минуты
Версию хранить в .env как то не логично, на мой взгляд. это не одно и тоже, что настройки подключений и т.п.

0

Сообщение от avtobys Wrong MVC

Как корабль назовёшь, так он и поплывёт: "Неправильный MVC"

0

Сообщение от voral иметь файлы проекта пользователя от файлов вашей среды разработки

там запланирован импорт пользователей со всеми принадлежащими им моделями(модулями неважно, как угодно)

Сообщение от voral а как изменения в БД производятся при обновлении

пока никак установка только с нуля, в т.ч. и файлы тоже.

Сообщение от voral после обновления сайт не открывается

я ж на psr-4 поменял, видимо поверх файлы закинули, composer dump-autoload и всё поедет.
с нуля установка работает, автоматически её чекаю перед отправкой коммитов.

Добавлено через 1 минуту
pgb, "правильность" в нашей жизни вообще очень скучная и примитивная штука.

0

Сообщение от avtobys я ж на psr-4 поменял, видимо поверх файлы закинули, composer dump-autoload и всё поедет. с нуля установка работает, автоматически её чекаю перед отправкой коммитов.

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

Кроме того после запуска команды композера еще не все изменения требующиеся

"Система установлена и есть зарегистрированные юзеры!"

т.е. надо править скрипт и убирать обратно строку

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

0

Сообщение от pgb Как корабль назовёшь, так он и поплывёт: "Неправильный MVC"

А ты как свой фреймворк назвал? Вот так же он и существует

0

Сообщение от Usaga А ты как свой фреймворк назвал?

Фактически никак ещё не назвал, нашёл короткий домен owni.ru(own собственный i я) планировал домашний сервер запустить с привязкой к этому домену. Фреймворк пока назвал OWNI(то есть без сторонних библиотек и с своим подходом) может переменную, а может и так сойдёт

0

0

Сообщение от voral я пытаюсь избразить же проект в работе, где нет возможности установить с нуля

пока что не предусмотрены обновления такого плана, будут обязательно, спасибо!
Насчет кнопочек голосования что обсуждали выше, по ограничению функционала. Там будут ещё шаблоны с типом html и они будут точно так же иметь группы доступа. Вот кнопочки и остальные любые блоки, которые не всем должны быть доступны, можно будет помещать в шаблоны с ограниченными правами доступа. Схематично как то так будет встраиваться:

0

Сообщение от avtobys Там будут ещё шаблоны с типом html и они будут точно так же иметь группы доступа

Представьте ситуацию
На странице у меня есть две формы быстрого заказа, волею дизайнера они имеют разные шаблоны т.е. на странице будет
Templates::html(777)
Templates::html(778)

Плюс еще endpoint принимающий ajax запрос этой заявки. А еще есть где то другая страница, где расширенная форма оформления заявки. В конечном итоге мы должны будем помнить что у нас относится к оформлению заявки и проставлять поотдельности права. Между тем, если бы у нас предоставлялись по функционалу (по модулям). Мы бы просто в одном месте открывали/закрывали.

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

Кстати предвосхищая... Может и такая быть ситуация.... На странице два блока одного и того же (в футере и в боковой колонке например форма подписки)

Templates::html(777)
Templates::html(777)

Этот шаблон подключает внутри себя (надеюсь это возможно) js и css файлы. И тут по хорошему надо бы, чтоб один и тот же файл не подключался в header.

1

Сообщение от voral Между тем, если бы у нас предоставлялись по функционалу (по модулям). Мы бы просто в одном месте открывали/закрывали.

Это уже реализовано дело в том что, - отключать и включать некий функционал целиком, а не по отдельности. Создаём группу - "оформление заявок", по сути наш определенный функционал. У шаблонов, эндпоинтов этого функционала группа доступа - "оформление заявок".
Включаем в неё всех существующих пользователей(я добавлю такой функционал, в пользователях, чтобы можно было включать массово пользователей из определенных групп в другие группы и исключать). Всё. Отключаем группу "оформление заявок" - функционал не доступен. Точно также, сейчас например группе демо юзеров, доступно 147 моделей, я же не буду лазить и из каждой их исключать, я просто отключу группу и всё что доступно им в панели админки станет недоступно.

Сообщение от voral Этот шаблон подключает внутри себя (надеюсь это возможно) js и css файлы. И тут по хорошему надо бы, чтоб один и тот же файл не подключался в header.

да надо будет подумать, да, спасибо!

0

0

voral, как теперь вам крон реализация, ничего не зациклит?
https://wrong-mvc.com/docs/cron.html
Циклить будет, очень качественно, с настройкой потоков для каждой задачи, их поддержкой, контролем за потоками и нагрузкой на сервер. Сейчас настройки задачи из бд дергаются каждый раз, эт конечно плохо в плане множества подключений, особенно для многопоточности, хоть и короткие запросы, подключения закрываются сразу, но всё же. Следующим этапом уйду от этого пожалуй, записи задач будут кешироваться в фс, при выполнении дергаться оттуда и обновляться при изменениях только. И тогда будет вообще огонь по батареям) У меря работало пару десятков парсеров с контролем потоков/нагрузки по такому принципу, схема отработана и отлажена давно, переживать приходилось только чтобы доноры выдерживали нагрузки))) по нескольку млн. страниц в сутки скорости обработок - на ура залетало с хорошими прокси конечно.

0

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

Решение правильное, но сразу предусматривайте возможность подмены кеширования. (Т.е. как минимум через интерфейсы). т.е. чтобы можно было для всего проекта переключить разом на другой сервис/тип кеширования. (в т.ч. написав свою реализацию). как пример кто то захочет Redis или Memcache

Добавлено через 6 минут

Сообщение от avtobys voral, как теперь вам крон реализация, ничего не зациклит?

Пока смущает только два момента:
1. По прежнему смущает что все через веб сервер.Почему бы для запуска из системного крона не реализовать отдельный контроллер.

2. Зачем exec. include не подойдет?

Добавлено через 9 минут
так же рекомендую в git другой порядок завести (вам же потом легче будет).

Т.е. коммиты называть именно по выполненной задаче. тут рекомендую посмотреть вот это видео (да и вообще этот курс интересный)

Версии указывать при помощи тегов

А на github добавлять релизы в соответствующий раздел
(имхо, вообще не каждый коммит является новым релизом )

Добавлено через 1 час 55 минут
В функции зарегистрированной register_shutdown_function идет добавление блоков html. Причем с гвоздями прибитыми стилями - это не очень правильно для универсального решения. Т.е. оформляете отдельным модулем/шаблоном/плагином кнопку "вернуться в аккаунт". И пусть разработчик где хочет там ее и вставит. При этом желательно, чтоб была возможность свой шаблон создать... Т.е, для примера, логика этого модуля решает показывать ее или нет (в вашем случае по анализу куки), если надо то подключает заданный шаблон.


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

1

Сообщение от voral сразу предусматривайте возможность подмены кеширования.

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

Сообщение от voral 2. Зачем exec. include не подойдет?

и как эффективно контролировать эти apache/fmp тогда? Они же не показывают какой именно скрипт выполняется. Писать что то куда то, флаги ставить опять же, это всё лишние ресурсы и неточность, а если их там тысячи будут в секунду, что то отвалилось, не так записалось, не в той очереди записалось. А по exec запустили и можем их в любой момент посчитать, вот они на ладошке все.

Сообщение от voral Причем с гвоздями прибитыми стилями - это не очень правильно для универсального решения. Т.е. оформляете отдельным модулем/шаблоном/плагином кнопку "вернуться в аккаунт".

да, будут же отдельные html шаблончики, это туда и будет встроено, спасибо за наводки)

Сообщение от voral так же рекомендую в git другой порядок завести

принято

Сообщение от voral Вы предлагаете визуально скрывать блоки доступ к которым запрещен текущему пользователю. По идее он вообще такие блоки не должен получать.

Нет, будут ещё и html шаблончики блоков, с правами доступов, вы уже меня на эту мысль навели, будет да крутяк, спасибо за советы и за интерес проявленный!) А этот вариант, он останется чисто для не критичных случаев(в плане безопасности) и чтобы не плодить эти шаблоны там где они не сильно то нужны, под каждую кнопочку/ссылочку. Ну есть страница некая, на ней голосовалка какая-то вызывается или модалка, или ссылка просто. Сама страница доступна как авторизованным так и не авторизованным, но функционал голосовалки/ссылки/модалки только авторизованным доступен, т.е. автоматически будет скрыт у гостей визуально средствами css. Наоборот очень хорошее решение, там где это не критично, мелочь какую то скрыть, чтобы не создавать под неё шаблон. Ну посмотрит он код, запросит недоступный request и получит 403. И будет вариант с шаблонами блоков, там уже будут до вывода проверяться его доступы.

0

Сообщение от avtobys ля крон задач это как раз не нужно, у них своё кеширование независимое от других сервисов должно быть.

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

Ну, а если хотите гибкости: ну можно сделать и там и там на уровне настройки. И я уже буду сам решать будет ли это один кеширующий сервис или разные.

Сообщение от avtobys и как эффективно контролировать эти apache/fmp тогда

Вы хотите своему решению слишком много ответственности дать.

Сообщение от avtobys там тысячи будут в секунду, что то отвалилось, не так записалось, не в той очереди записалось

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

Кстати, у вас там в крон стоит время работы скрипта 90сек.... некоторые задачи на проектах вполне себе минут по 10 -20 выполняются.


PS Настоятельно рекомендую изучить PHPUnit и взять его на вооружение. Он вообще крайне полезен. Тем более для инструмента такого рода, тем более в стадии активной разработки.

0

Сообщение от voral у вас там в крон стоит время работы скрипта 90сек.... некоторые задачи на проектах вполне себе минут по 10 -20 выполняются.

выполнение каждой отдельной задачи в cron.php происходит из под cli в любом случае, и set_time_limit там не учитывается же, поставлю даже 61 сек норм. Там же разделение на потоки происходит и они уже из exec выполняются. Могут выполняться 1000 потоков часами и не зависеть друг от друга никак, и от остальных задач тоже.
set_time_limit там 61 будет, это для ежеминутного цикла cron.php по курл http запросам. Например, ничего не запущенно ещё. Пользователь заходит на сайт в 00:00:03 заинжектилась картинка cron.php ему, стартанулись автозапуски, 57 секунд скрипт подождал до начала следующей минуты и в 00:01:00 запустился снова и дальше погнал четко каждую минуту себя запускать
Чтобы не зависеть от пользователя и автозапуска курлом(может же оборваться) можно дополнительно обычный системный крон поставить ежеминутно wget или curl на выбор, вреда не будет и всё вообще четко будет.

Сообщение от voral Почему?

крон задачи не должны зависеть от каких то сторонних сервисов

Сообщение от voral Не в той очереди - а как такое может быть? сейчас подобная задачу я решаю следующим образом: первая задача выполняется - если отработала полностью и успешно - она же ставит в очередь другую задачу. вот и все - очередность гарантированна.

есть высонагруженная многопоточная задача, её надо запускать в 900 потоков, парсим например что то активно. Логика блокировок и очередности чтобы парсер не качал одну и туже страницу(гарантировать очередность выполнения задачи) - это головная боль разработчика парсера, сейчас не об этом речь, а за контроль самого количества потоков задачи. Потоки могут падать в любой момент, выполняться с разной длительностью и т.д. Нам же надо контролировать количество этих потоков и управлять ими - увеличивать/уменьшать их количество. Писать что то, куда то, вот поток запустился, вот поток выполнен, - это ерунда не эффективная и бажная, проходили. exec('command &') и ps aux | grep-аем затем строку команды задачи.

Сообщение от voral Вы хотите своему решению слишком много ответственности дать

как раз наоборот, слишком много ответственности - это возлагать контроль за потоками на них самих или ещё на что то. Я так делал когда то, многопоточные парсеры, записывал файлами потоки, их состояния, время, чтобы очищать упавшие потоки, таккккая фигня, всё равно приходилось лезть регулярно что то поправлять, а скорость выкачки требовалась космическая. Потом перешел на это решение и 4 года они у меня работали и качали всё как часы.

0

Сообщение от avtobys крон задачи не должны зависеть от каких то сторонних сервисов

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

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

Сообщение от avtobys есть высонагруженная многопоточная задача, её надо запускать в 900 потоков, парсим например что то активно. Логика блокировок и очередности чтобы парсер не качал одну и туже страницу(гарантировать очередность выполнения задачи) - это головная боль разработчика парсера,

вообще не проблема. Создаем очередь ссылок потоки, сколько запустим столько и будут с этой очередью работать. Проверено проблем вообще ни каких. И балансировку тоже делал. Просто грубо говоря писал в специальный конфиг, сколько брать за шаг в обработку. такое делал и на парсиге и на генерации каталога (порядка 200 тыс товаров генерируется вместе с картинками).

Сообщение от avtobys Писать что то, куда то, вот поток запустился, вот поток выполнен, - это ерунда не эффективная и бажная, проходили

Не знаю, вообще ни разу не подвела. Это решение работает в нескольких вариантах не первый год и вообще не требует внимание. Все четко.

Ну тут, не приницпиально... если уверены что проблем не даст пусть так....

Сообщение от avtobys как раз наоборот, слишком много ответственности - это возлагать контроль за потоками на них самих или ещё на что то

Ну тогда надо всю ОС на php переписать всему где то есть пределы.

Сообщение от avtobys Потом перешел на это решение и 4 года они у меня работали и качали всё как часы.

Та технология, которую я пытался описать работает очень давно, нареканий ни у кого не вызывает. Я лично с 2009 года. Вот те задачи с распараллеливанием, из тех что делали лично я, (где было относительно больше нагрузки - если не ошибаюсь с года 2012 на одном проекте работает). В т.ч. и задачи парсинга были. и работа с АПИ сразу нескольких криптобирж, вообще чуть ли не реалтаймовая была...

0

Сообщение от voral первая задача выполняется - если отработала полностью и успешно - она же ставит в очередь другую задачу. вот и все - очередность гарантированна.

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

Сообщение от voral по хорошему они должны быть тонкими - просто вызывать различные "сервисы" вашего проекта"

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

Сообщение от voral Это совсем не сторонний сервис. Это часть системы.

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

Сообщение от voral Ну тогда надо всю ОС на php переписать всему где то есть пределы.

у меня в одном проекте в одном и том же файле из под php через exec юзался bash, python и nodejs, код вырви глаз))) с одной стороны, а с другой если что то позволяет эффективно и без дополнительных танцев с бубном реализовать задачи, то почему бы это не использовать, а ограничивать себя рамками только php.

Сообщение от voral Создаем очередь ссылок потоки, сколько запустим столько и будут с этой очередью работать. Проверено проблем вообще ни каких.

Я так понимаю эти ссылки вы куда то записываете, верно? ок, а перезапускаем сервер, что с этой очередью будет? Для программы они до сих пор выполняются, надо там что то очищать то есть периодически, предусматривать это всё, перезапуски, падения потоков. А тут мы по сути те же "ссылки" потоков записываем в ту же "очередь" выполняя их в фоновом режиме "php -f cron.php 777 &" и имеем над ними полный реалтайм контроль.

0