Есть ли желающие изучить очедерной PHP фреймворк?

2) Install Node.js
PHP фреймворк

Ясно.

Уже.

Ясно.

Обычное дело сейчас. css'ки компилить.

очедерной PHP фреймворк

https://morpho-os.github.io/

Что такое Morpho? Morpho это система для разработки программ. Она соcтоит из:

ОС - Arch Linux

Набора языков программирования

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

И что?

Это странно.

Нахрена оно нужно, если есть laravel/symfony2/yii2?

Чтоб css занимали по 3 метра и скрипты метров по 15. И гадай что дольше - загрузка, рендер сайта или выполнение скриптов.

Чтоб css занимали по 3 метра и скрипты метров по 15. И гадай что дольше - загрузка, рендер сайта или выполнение скриптов.

Ну тут ты не прав. Результатирующий при использовании всяких scss/typescript получается небольшой. А писать таки удобнее.

Ну фреймворк Morpho, есть система в которой он может использоваться, тут он есть в списке. Я помогаю с освоением только фреймворка в данном топике.

Раз вы знаете про laravel/symfony2/yii2, может тогда попробуете Morpho и решите сами? Правда нужен PHP 7.

а если я не хочу использовать mysql? как мне быть?

Раз вы знаете про laravel/symfony2/yii2, может тогда попробуете Morpho и решите сами? Правда нужен PHP 7.

Итого, в итоге сейчас есть только ссылка на гитхаб. Ни документации, ни перечня каких-то киллер-фич.

А что в composer.json:

1) используется довольно мало сторонних либ, значит все остальное в фреймворке - собственные велосипеды. В которых явно могут быть проблемы и которые надо поддерживать. А судя по истории коммитов и количеству issues ресурсов на это явно нет.

2) а те библиотеки, которые испольуются завязанны на dev-master. Тоже очень забавное решение.

Короче, сейчас не видно ни одной причины, чтобы тратить на это время и смотреть.

Посмотрел пару коммитов и вообще исходники. Нафиг-нафиг. Если у вас что-то на этом написано, то развивать это еще имеет смысл. Но начинать на этом что-то новое смысла нет от слова совсем.

Я помогаю с освоением только фреймворка в данном топике.

А какие вообще могут быть трудности с освоением пыхпых-фреймворка? Что в нем сильно отличающегося от существующих?

Хотя даже если есть что-то, что на этом написанно есть смысл переписать.

Ласипед из десяти.

Алсо, пашкиным/марковым конпелятором оно хоть собирается?

PHP 7 framework
Install Node.js

Досвидания

А какие вообще могут быть трудности с освоением пыхпых-фреймворка? Что в нем сильно отличающегося от существующих?

Отсутствие документации. Отсутствие сообщества. Странные подходы к дизайну. Игнорирование существующих psr.

PHP 7

закопать

nodejs

и это тоже

PHP
2016

Не нужно.

Нужно определить каким конкретно образом вы не хотите использовать MySQL.

Если вы пишите веб-приложения, можно выделить несколько уровней нехотения:
1. Не хочу использовать полностью, хочу другую СУБД - тогда нужно будет реализовать несколько своих классов и изменить зависимости в ServiceManager. Если пойдёте этим путём могу помочь в этом.
2. Хочу использовать др. СУБД вместе с MySQL - подключайте и используйте.

Если вы пишите CLI-скрипт/приложение, и не хотите использовать MySQL - не используйте - другие классы доступны. Для CLI можно сделать так - создать файл /usr/local/lib/morpho.php и прописать в php.ini в include_path путь /usr/local/lib. Содержимое morpho.php:

require '/home/user/project/morpho/src/vendor/autoload.php';
require LIB_DIR_PATH . '/Morpho/Cli/bootstrap.php';

require 'morpho.php';
d(class_exists('\Morpho\Base\Object'));

Ну писать для production я бы не советовал, а вот попробовать стоит одназначно.

Вы ещё говорите

Посмотрел пару коммитов и вообще исходники. Нафиг-нафиг. Если у вас что-то на этом написано, то развивать это еще имеет смысл. Но начинать на этом что-то новое смысла нет от слова совсем.

Можете обосновать почему нафиг-нафиг касательно исходников?

Насчёт

Игнорирование существующих psr.

На самом деле не всех, а некоторых частей, некоторых PSR.

Трудности могут быть разные в зависимости от вашей среды и навыков, например:
* трудности установки и настройки среды для работы c фреймворком;
* трудности, связанные с отстутствием понимания структуры модулей;
* трудности, связанные с отстутствием знаний API.

Какие фичи?

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

<?php echo $foo ?>

<?php echo htmlspecialchars($foo) ?>

* опечатка:

* Принципы работы как и в других контроллерах: роутинг -> диспатчинг -> рендеринг.

должно быть:

* Принципы работы как и в других фреймворках: роутинг -> диспатчинг -> рендеринг.

а если я не хочу использовать mysql? как мне быть?

никак, будешь юзать скулайт =)

Мне чот кажется, что фреймворк сделали хипстробитриксоиды.
Хотелось бы больше выбора по БД. Иногда вместо мускула полезно юзать постгрес. Да и если нужно вместо реляционной юзать не реляционную бд?
О там кложур есть ^_^ https://morpho-os.github.io/spec/components/programming-languages.html

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

окей, в сухом остатке - шаблоны с PHP-синтаксисом.

может там есть какие-то архитектурные инновации? Чтобы был смысл в создании нового фреймворка

или может тогда прикрутить новый движок шаблонов к симфони да и успокоиться?

* трудности установки и настройки среды для работы c фреймворком;
* трудности, связанные с отстутствием понимания структуры модулей;
* трудности, связанные с отстутствием знаний API.

а в документации этого нет? зачем нужен такой фреймворк?

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

Symfony 2 рассматривался в своё время, так же как и многие наличествующие фреймворки, Zend Framework 1, 2, Nette, Yii, Doctrine 1, 2, многие CMS. В одних не устраивала архитектура, в других не было чего-то важного, в третьих была излишняя усложнённость, четвертые были неудобные и т.д. Из того, что пробовал больше всего устраивал ZF 1, но основные компоненты 2 ZF были переделаны так, что потеряли качества ZF 1 и не устраивали по многим причинам. Поэтому было принято решение писать отдельный фреймворк.

окей, в сухом остатке - шаблоны с PHP-синтаксисом. может там есть какие-то архитектурные инновации? Чтобы был смысл в создании нового фреймворка

Я бы сказал, что есть вещи, которых вы не найдёте нигде.

или может тогда прикрутить новый движок шаблонов к симфони да и успокоиться?

Если вас устраивает симфони и устроит то, что будет сделано, пожалуй да.

Ещё хочу заметить - одна из фишек - в фреймворке есть как backend, так и frontend модули, проработано их взаимодействие. Код на TypeScript можно встраивать в страницы путём включения специальной директивы в HTML. Включённые файлы будут перекомпилированы при изменении.

Отсутствие документации. Отсутствие сообщества. Странные подходы к дизайну.

зачем тогда нужен этот фреймворк? ;)

Игнорирование существующих psr.

ну, это как раз, не так и страшно, имха

Документация будет позже. Пока мне важно ваше мнение узнать, получить feedback, чтобы скорректирвоать план.

Да, в модулях вы можете юзать любую СУБД. Например, сейчас у меня в одном из модулей работает Neo4j. PostgreSQL можно будет юзать, нет привязки к вендору, используется стандартный синтаксис SQL, а если нет, то это баг. Схема задаётся в PHP, по PHP генерятся таблицы.

Документация будет позже.

Без документации не будет никакого «позже». Широкому кругу пользователей (программистов) не нужен код без документации. Совсем. Абсолютно.

Хорошо, будут доки. О чём написать в первую очередь в доках? Я планирую что-то вроде «Быстрого старта».

1. Установка и настройка.
2. Пример создания модуля.

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

Хорошо, будут доки. О чём написать в первую очередь в доках?

Имхо как-то так:

1. Quick start guide
2. Architecture overview
3. Example sites (и побольше разных)
4. API documentation

Хорошо, спасибо за эту инфу, принял во внимание.

О чём написать в первую очередь в доках?

Кратко кто за этим стоит и сколько народа это разрабатывает. Т.к. брать что-то большое с bus factor = 1 желания нет. Поддерживать чужие брошенные либы/фреймворки совсем невеселое задание.

Можете обосновать почему нафиг-нафиг касательно исходников?

Изменение public на protected(что по сути является bc). Обработка кодов 400 и тд используя header+exit.

О чём написать в первую очередь в доках?

А вообще, еще лучше в доках написать ПОЧЕМУ стоит это попробовать.

Так как пока как киллер-фичу вы преподнесли только php-like шаблонизатор.

Я бы сказал, что есть вещи, которых вы не найдёте нигде.

вот и хочется услышать про эти вещи :)

В доках постараюсь, чтобы были описаны возможности.

Код 400 используется в самом начале обработки, когда дальше не имеет смысл обрабатывать запрос - это случай когда $_SERVER['HTTP_HOST'] содержит неверное значение. $_SERVER['HTTP_HOST'] используется для определения текущего сайта при включении мультисайтинга. Возможно над этим стоит поразмыслить лучше, но пока как мне видется нужно описать архитектуру в документации.

Кратко кто за этим стоит и сколько народа это разрабатывает. Т.к. брать что-то большое с bus factor = 1 желания нет. Поддерживать чужие брошенные либы/фреймворки совсем невеселое задание.

Разработкой занимается компания, сейчас сайт компании ещё не готов, так что я не могу его показать. Идёт формирование команды, поэтому пока кол-во разработчиков неопределено. Пока считайте, что делается одним человеком, но в будущем это изменится и над ним будет работать команда. Фреймворк уже используется в production, но API ещё не стабильно настолько, чтобы быть готовым для использования не во внутренних production проектах. Лицензия Apache 2.

Интересно, подпишусь на тред. А в двух словах, что за киллер-фичи?