Комментарии 73
Что-то маловато кода на Github.
Максим, Вы не рассматривали для своей разработки на php - FuelPHP Framework?
Как мне кажется к FuelPHP стоит присмотреться. Его совершенно не заслуженно обходят стороной в угоду Laravel.
Спасибо за наводку. Обязательно ознакомлюсь.
Вы же шутите же, правда? Ну правда же? Ведь невозможно всерьёз в 2022 году рекламировать фреймворк, который архитектурно остался в 2010?
Как мне кажется к FuelPHP стоит присмотреться.К сожалению, мне по работе приходится использовать этот клон Kohana, устаревший уже на момент своего появления. Даже по сравнению с более старыми фреймворками (например, Yii 1.1) FuelPHP выглядит доисторическим ископаемым.
Например, в нём отсутствует DI — от слова «совсем». Никакой автоконфигурации своего компонента нет и быть не может: все значения из файла конфигурации надо вытаскивать вызовами статических методов класса Config.
И, кстати, статические методы классов ядра фреймворка придётся использовать на каждом шагу: это самое ядро как минимум на половину состоит из классов, имеющих только статические методы. Если же такой класс может иметь несколько конфигураций (как, например, несколько подключений к базам данных), то имя отличной от дефолтной конфигурации придётся задавать в виде текстовой строки в вызове метода.
Какой чудесный новый фреймворк! Я давно этого ждал, и что не мало важно - отечественный с 20 летнем опытом! Всякие ваши забугорные симфони и ларавель такая шляпа!!! Скажите, а как вам можно перевести 10.000$ в рублев*м эквиваленте на разработку вашего фреймворка? А то у меня стартап отечественный я без вашего фреймворка не смогу!!! И код кстати - восхитительный! Всем советую новый проект начинать на этом и не делать код ревью!!!
Кстати, а вы код Doctrine видели? Рекомендую посмотреть.
Код Laravel тоже интересный местами, как и подход его создателя.
Я видел молодой человек, и доктрины и Laravel, все по стандарту и читаемо, хотя бы пробелов нету:
$this -> class = $settings['class'];
$this -> setKey($settings['key']);
$this -> method = $settings['method'];
итого - 3 минуса значит 3 чуда проекта на этом фреймворке, кто покажет свой исходный код??? Что бы мы все могли оценить как нужно делать настоящие веб приложения!
Да, вы безусловно правы. Код нужно еще будет причесывать. И не только под синтаксис, но и под использование современных подходов к проектированию, SOLID например. Но это ведь не значит, что код не рабочий или его нельзя использовать.
На мой взгляд, любые технологии развиваются, меняются стандарты. И любой проект также должен развиваться.
Хейт тоже полезен. Я конечно же учту вашу критику, тем более что в ней много рациональных и совершенно справедливых суждений.
Так что спасибо за комментарии.
Я работаю над проектом и стараюсь, чтобы он становился лучше.
В очередной раз пройдемся по этому мертвому списку с очередным "автором" фреймворка (Вы бы хоть предыдущие статьи в этом хабе почитали тк там уже было дано тысяча и один совет как надо и как не надо).
PSR
Хотя бы 1 линтер
Что касается документации - пишите ее в коде (да, так можно) а потом генерируете из нее веб доку
Из этого вы сделали - ничего и говорите что все сделаете потом (когда потом? если можно было сразу все это делать)
Технологии уж точно развиваются, и я ничего не говорил про SOLID, я в этот раз про качества кода молчал!
Я просто не представляю как вообще этим можно пользоваться? какая польза, как вообще написать на этом хоть что нибудь сложное? Да если взять это для проекта нормального, все придется выпилить и поставить другие компоненты!
Вот скажите, почему вы как автор фреймворка не сделали example любой хотя бы бложек, с авторизацией там, комментариями где бизнес логика выйдет за 3 строчки и ваше чудо себя раскроет на полную! Нет, не сделали время нету, зато статью опубликовать вы время - нашли легко!!!
Как можно пользоваться таким и выкладывать это на хабре если у вас нет времени этим заниматьcя???
Вы меня опередили с этими вопросами, чуть ниже умудрился задать автору их же. Честно, складывается впечатление некой полукоммерческой cms, чем реального фреймворка.
Нет-нет, вы меня неправильно поняли. Я много времени уделяю проекту. Я говорю, что его, то есть времени, катастрофически не хватает, потому что я сильно отстаю.
Еще раз благодарю за комментарий. Конечно же, я приведу и код, и документацию в порядок. Вы правы, публикация кода в таком виде это пренебрежение временем форумчан. Моя оплошность, но это не намеренно.
Надеюсь, это не отпугнет вас от рассмотрения моего фреймворка в дальнейшем.
От чего отстаёте, куда опаздываете?
Спуститесь с небес на землю. Начните писать с современным подходом к разработке и Вы поймете, что ничего НОВОГО Ваш фреймворк предложить не может.
Сейчас Symfony/Laravel/Yii2/Spiral покрывают 99,9% потребностей разработчиков на фреймворках. Остальные пишут вообще с нуля полностью своё.
Тем-более что Вы называете свой проект фреймворком, хотя у Вас получается франкенштейн, наполовину CMS, наполовину (простите) фреймворк.
P.S. Вы куда то там отстаете (хотя непонятно куда), но зато сделали и сайт, купили домен, сделали аккаунты на ютубе и инсте (ныне заблокирована в РФ), сделали канал и чат для обсуждений в телеге, и ради чего? Вам не кажется, что Вы начали распылять свои силы еще до того, как проект готов? Я Вас понимаю, хочется быстрее, быстрее показать свой шедевр, и получить признание сообщества, поддержку, но в итоге-то вышло наоборот.
Поддерживаю, создатель ларавеля не анонсировал его до тех пор пока не сделал полную доку
Ну да. Ни статьи, ни сайта. Может стоило сначала причесать? А пока даже смотреть не хочется и тратить время.
Да, документация хромает, это верно.
Мне действительно очень жаль, что не могу предложить вам полноценную качественную поддержку. Но буду стараться.
Насчет причесать, я и правда думал над этим. Возможно, вы правы. Но здесь - вопрос времени. Действительно сложно тянуть весь процесс в одиночку.
Моей целью было познакомить сообщество с новым фреймворком. Я думаю, цель, хотя бы частично, достигнута. Безусловно, я не остановлюсь на этом.
Нужно больше синглтонов богу синглтона!
Реактивность... Скрипт проверяет страницы шаблона с заданным интервалом, и если есть изменения, перезагружает ее.
А что вы понимаете под реактивностью? В общепринятом значении - это потоковое распространение событий и реагирование на них. А у вас?
Интересно, а на 1ЭС можно разработать сайт?
Да, там есть возможность обрабатывать HTTP запросы различными способами. Есть уже даже готовые "проекты", например https://infostart.ru/public/274186/. Но лучше всё-таки использовать её как поставщик API, очень удобно получается.
Используя термин "отечественный" вы берете на себя ответственность за соблюдение высокого уровня качества. И как минимум странно, что проект на таком уровне готовности идет в сообщество. Вот прям хочется, чтобы был свой фреймворк уровня Laravel/Symfony/Yii, но пока не доработано. Верим в вас и надеемся на лучшее.
Теперь по технической части:
Зачем везде закрывающие теги ?> ? Их не просто можно, их нужно убрать, чтобы избежать одной очень древней ошибки с спецсимволами.
Что за инструмент вы используете при разработке, что получается такое форматирование и комментарии к функциям внутри функций?
Чем вызвано использование старых версий PHP, вместо наиболее актуальной PHP8.1, обладающей значительными преимуществами?
Переадресация с http на https и www на без www - это исключительно компетенция веб-сервера, почему вы пытаетесь взять это на себя?
Наверное, редкий PHPшник не делает свой фреймворк. Больше фреймворков хороших и разных богу PHP-FIG. Полезный опыт. Смутило позиционирование "отечественного" на "враждебном" домене и хостинге. Кстати, в России композер нормально работает? У меня лозунги пишет политические, а у вас?
Про composer https://habr.com/ru/post/661017/
Честно говоря если бы не сообщили про 20 в разработке, возможно бы все сгладилось. Однако наблюдая код проекта, небрежность в структурировании и отсутсвие общепринятых стандартов - этот проект сложно будет привести в норму и 20 лет опыта к сожалению кажутся неправдой… не говоря о том, что поддержке php 7.4 остались считанные месяцы, а поддержка 8.0 должна истечь в следующем году.
Вашу разработку надо приводить к 8.1, начать декларировать и соответствовать общепринятому psr-12. А учитывая увиденное, это потребует не малых сил и вложений своего времени, к сожалению :(
Возможно, вам будет интересно: ссылка на отечественный query builder собственного велосипедопроизводства. Правда, ему уже миллион лет, и надо адаптировать под современные реалии, но комментарии и структура на месте. Когда-то был частью самописного CMF, но его концепция давно устарела, как мне кажется. Раз уж продвигаете отечественное, может, подхватите знамя.
Спасибо. Обязательно гляну.
Извините, но это конечно совершенно не подлежит восстановлению. По многим причинам.
Пара советов на будущее, если соберётесь делать что-то подобное
- поддержку разных СУБД лучше делать через PDO. Это значительно сократит трудозатраты на написание драйверов
- заниматься подавлением ошибок не стоит. Это не приносит ни малейшей пользы (скрыть ошибки от пользователя можно гораздо более простым способом) а вот скрывать ошибки от себя самого — это стрелять себе сразу в обе ноги, и заодно контрольный в голову
- от квери билдера мы ждём удобства и защиты от инъекций
- извините, но
$result = $db->select(true, false, $db->noJoin($config));— это совершенно не то, чего мы ждём в от квери билдера в плане удобства - увы, сейчас в коде дыры почти в каждом методе, от оrder by до insert
- извините, но
О, вы меня неверно поняли, я на php не пишу уже некоторое количество лет, так что ничего подобного писать не соберусь, а если бы т собрался, то делал бы совсем не так. Если что, сам код прямиком из 2009-2010, с PDO тогда было так себе, адаптировано под php7 перед непосредственной публикацией на GitHub (дату коммитов можете посмотреть). Просто мне показалось, что код хорошо подойдёт данному проекту. Насчёт best practices в php вообще ничего сказать не могу.
Ну, вообще-то защита от SQL инъекций — это не "best practice", а как бы проверка на профпригодность. Причём в любом языке. Вот прямо сейчас на стековерфлой пришёл какой-то кадр, который вывалил кусок исходника мессенджера Блаббер на Яве, и такой просит, "мне написали, что тут SQL инъекция, кто может пофиксить"? И единственный вопрос, который у меня возникает — это "а он этому коду вообще кто"?
Про best practices имел ввиду ваше замечание про подавление ошибок, а не про защиту от инъекций. По поводу того, что человек спрашивал: так бывает, что назначили на какое-то легаси, а разработчик новичок или всегда пишет только с использованием ORM (что также вызывает вопросы, но, к сожалению, в наше время не редкость).
Про удобство с вами полностью согласен, именно поэтому во время публикации на гитхабе рука дальше нескольких правок под php7 дело и не пошло - не увидел смысла. Но, быть может, автор проекта что-то для себя оттуда почерпнет, или нет.
Ну и для проформы: вы сказали, что методы дырявые, на примере insert можете указать на конкретные места, я так понимаю, вы ознакомились с кодом немного?
Автор, в https://github.com/isengine/isphp довольно много ошибок, код с 8.0 не вполне совместим - попробуйте Inspect Code, который встроен в PHPStorm. Про игнорирование стандартов PHP-FIG уже написали.
Дабы понять комментирующих здесь объективно, прошу изучить https://github.com/spiral/framework разработанный нашими белорусскими коллегами. Архитектура, поддержка стандартов языка, общая семантика/дизайн кода и тд и тп. «Фреймворк» не обязан быть «отечественным», он просто должен быть качественным конструктором, с заделом на будущее (определенная степень провидения обязана быть), иначе не стоит мучать себя и сообщество мертворожденным кодом..
PS: не могу сейчас корректно сформулировать мысль дабы двусмысленностью вас не задеть или обидеть, приношу извинения тем не менее, но посмотрите на уровень разработки, кода, инструментария в Spiral. Именно уровень разработки и мысль, вложенная в продукт, показывает будут им пользоваться миллионы или только вы..
Спасибо. Обязательно посмотрю
но посмотрите на уровень разработки, кода, инструментария в Spiral.
Ну раз пошла такая пьянка: Когда ещё работал над спиралью — возникло много вопросов по всяким легаси компонентам. Хотели на чистовик переписать, так что в свободное время набрасывал концепт 3ки.
Качество кода там, по-моему, ещё выше. Как и все эти метрики, вроде коплинга и кохижена… Можно смотреть, имхо, в качестве пособия как надо писать современный код (ну или я просто ЧСВ и подвержен Даннингу-Крюгеру): https://github.com/helix-php/helix
прим.: Так как сделано было по-быстрому, то тестов и доки нет. Но код там не особо сложный и читается довольно просто.
Но в результате на конкретно этот вариант 3ки забили болт, концепт который я делал не одобрили (тупо не дали время на фулл тайм доработку), а когда уходил из Spiral Scout — выложил своё решение в ОС. Не валяться же ему в приватных репах, тем более сделанное в свободное время =)
Таким вот должно было быть ядро Spiral 3 по моим представлениям. Но не случилось.
Но вообще, некоторые концепции из неё перекочевали в Cycle ORM: Например строготипизированные конфиги на основе DTO, концепцию которых я почерпнул из Vulkan API.
Кирилл, спасибо за труд! И за предоставленную ссылку, пороюсь сам с удовольствием. За Cycle ORM слежу, недавно попал на весьма интересный bridge https://github.com/spaceonfire/spaceonfire/tree/3.0.x/pkg/cycle-bridge вот где современный код, чистенько и аккуратно все и заодно и Cycle сам поразглядывал миллиметр за мллиметром
Неймспейсы с маленькой буквы разве что немного раздражают. В пыхе такое не прижилось, так что секция use вкыглядит оляписто чуток.
В остальном да, довольно прилично. Даже ассерты используются, что довольно редко практикуется для контроля типов.
По поводу неймспейсов стандартом не запрещено, значит можно, на вкус и цвет конечно. Я много идей у Константина подхватил в коде, попросил его сделать демку с этим бриджем - вот https://github.com/hustlahusky/spaceonfire-demo-app Реализация коллекций тоже собственной разработки, утащил к нам в битрикс ^_^ а то печаль же совсем..
Заглянул ради забавы посмотреть что люди в комментах пишут. Совсем не ожидал что тут и мою работу обсуждают и с некоторой стороны даже хвалят. Спасибо @eshimischi, что поделился тут ссылкой!)
Касаемо неймспейсов - согласен, самому не очень нравится как они выглядели, поэтому сейчас компоненты в процессе переезда в новую организацию с простым, коротким неймспейсом с заглавной буквы)
За качество не жалко! Спасибо за труд, будем следить за дальнейшим развитием! По поводу неймспейсов, на вкус и цвет, сам конечно всегда использую с заглавной буквы, но встречаются и такие варианты - это не беда. PS: это я писал на github тебе с просьбой сделать boilerplate, так как документации не очень много, не совсем понятно как использовать spaceonfire инфраструктуру без примеров, спасибо еще раз!
Привет, Кирилл!
Spiral Framework пошёл эволюционным путём. Всё легаси помечается deprecated в двойке и уже выпилено в будущей тройке. Завязки на внешние компоненты выносятся в бриджи в виде отдельных пакетов. Всё будет хорошо :)
Привет, Алексей!
Боюсь это и погубит SF. Сейчас в фреймворке вы занимаетесь тем, что боретесь с легаси, а не приносите что-то концептуально новое, что должно стать геймченджером.
Не, это конечно не плохо, стабильность и все дела… Но, боюсь, упускаете момент настолько, что FrameworkX от Clue, который появился всего пол года назад и не имеет ничего, кроме, грубо говоря роутера, уже, за эти самые пол года набрал половину аудитории от Spiral Framework. А я хочу напомнить, что Framework X изначально выходил как концептуально устаревшее решение, построенное на промизах, а не файберах.
У меня несколько вопросов.
Шаблонизатор имеет огромные возможности. Например, вы можете создать несколько админок
Можно пояснить, что означает эта фраза? В моем понимании шаблонизатор и админки — это совершенно никак не связанные вещи. И почему несколько?
Мне кажется, это будет полезно не только нам, но и в других странах, особенно где не используется латинский алфавит.
Можно здесь тоже пояснить? В чем именно заключается особенная польза? И почему она не распространяется на страны, где используется латинский алфавит — ну например Норвегию? или здесь всего навсего имеется в виду поддержка строковым хелпером функций mb_string?
use is\Helpers\Prepare;
/ Класс, который производит очистку данных по заданному параметру например, перед передачей ее для записи в базу данных на входе нужно указать значение $data и тип преобразования $type
Здесь тоже можно пояснить? Как именно предполагается "очищать" данные перед записью в базу данных?
И отдельный вопрос, в чем смысл большинства таких "очисток"? Например, мы разрешаем только буквы и цифры или там емейл, а нам приходит строка с пробелами и пунктуацией. В чем смысл сохранять заведомо некорректные данные?
И ещё отдельный вопрос, в чем смысл метода Prepare::script()? Что он делает такого, чего не делает stripTags()?
https://github.com/isengine/isphp/blob/master/Helpers/Ip.php
Здесь у меня очень короткий вопрос. Серьёзно? Последний раз всего две недели назад обсуждали. Не говоря уже про классический труд на тему "Я знаю крутой способ определить настоящий всамделишный IP адрес, и утру нос всем хакерам!".
И последний вопрос. Я правильно понимаю, что ни с одной СУБД фреймворк работать не умеет, а качестве базы данных используется собственная разработка, обладающая такими уникальными возможностями как настраиваемый разделитель полей — можно использовать как двоеточие (:), так и палочку(|)? Ну или в лучшем случае — папочки с JSON файлами?
Это разработка 1 человека. Ну, можно конечно считать это отечественной разработкой. Если автор занимался этим работая в гос. конторе. А так - хобби-проект.
ЗЫ: особенно доставляют коммиты "Update defaults.zip", их десятки. Информативненько.
Автор, начну с вот этого:
Если вы хотите помочь фреймворку, начните использовать его в своих проектах.
Для того, чтобы начать его использовать в своих проектах, вы должны меня убедить. Например, показать сравнение скорости работы вашего фреймворка и Laravel, Syphony etc., показать рабочие примеры, вот сразу вопрос - сайт isengine использует этот фреймворк? Дальше, чем ваш фреймворк лучше фреймворков с более чем 10летней историей? Может быть у него есть то, чего нет у других фреймворков?-тогда нужно об этом рассказать нам ведь.
Далее, зачем вы в презентации( назовем это так ) продукта рассказываете о том, какой вы путь прошли? Когда я читал, полагал, что вы плавно перейдете к трудностям, с которыми столкнулись и которые вынудили вас написать этот фреймворк, который эти трудности благополучно решает, ан нет.
Друзья, всем пример.
Наверное все-таки привет.
Почему-то сложилось мнение, что пользуясь отечественным, вы почти всегда получаете продукт более низкого качества, чем зарубежный аналог.
Вы перед нами оправдываетесь или зачем это вообще сообщать? Вы не уверены в своем продукте?
Что еще? Есть автогенерация SEO, различных меню.
А ORM, AR, Middleware где? Или это будет?
Сейчас я приступаю к работе над релизом.
Убедительно прошу вас - не приступайте! Для релиза это катастрофически мало.
Я надеюсь это какая-то метаирония или что-то в этом роде
Отечественный jquery 22 года 20 века. Встречайте!
Пожалуй я тоже оставлю свое мнение. (Моя речь - жесткая, но я затронул всё, что мне как разработчику/пользователю этого фреймворка не нравится)
Да, кода написано много, однако 5 лет разработки - ложь (можно отследить по комитам), даже если это правда, то у меня для вас плохие новости.
Раздел: Начнем с основ.
Что такое фреймворк? Фреймворк - каркас, ускоряет разработку сайта. Если вы смотрели в структуру директорий, то можно заметить, что есть целая папка, которая уделена установке... Зачем? У нас разработчики уже не хотят менять пару строчек в коде? В этом нет никакого смысла. Фреймворки как раз и ценятся, потому что их можно быстро настроить, не надо разворачивать свой хостинг, чтобы открыть страницу. Хотя судя по тому, что в папке public_html находится всего один файл, можно сделать вывод, что автор руководствовался правилом "у других так, а я чё, лох?". (речь идет о современных фреймворках и opencart)
Раздел: О коде
Бог с этими ненужными действиями ним, зачем было вставлять два языка комментариев в коде? (английский и руский) и даже это можно опустить, но закоментированные куски старого кода... просто жесть, а не, жесть идет дальше, ведь дальше мы видим Вот это
И ладно, вторую фотку ещё можно понять свой стиль и т.д, но объявлять сокращённые константы с проверкой на существование этих констант... (после увиденного я непроизвольно сделал фейспалм). Можно подумать что хуже уже не будет, но снизу снова постучали
Честно, я такого кода даже на wordpress не встречал, а здесь целый культ, пришедший прямиком из начала 2000-х. Что это? Если это находится в папке template, то разбей ты уже это на части. Франкенштейн не будет выглядеть страшно, если взять только руку.
Раздел: Когда беды с башкой уже общая проблема
Я смотрел код < 20 минут, я не берусь судить, может это инновационный продукт, однако фраза "От разработчиков для разработчиков" не имеет смысла, если непонятно что вообще происходит. Может стоит перевернуть экран?
Раздел: Итог
Я потратил ~50 минут своей жизни, чтобы вы не тратили свою. Если так хочется разрабатывать продукты, то разрабатывайте, но убедитесь, что они нравятся людям. Не пишите громких заявлений на пустом месте. Если бы эта статья говорила: "Я сделал фреймворк, ща объясню что за концепцию я заложил и вот вам ссылки", то вместо возмущений, были бы слова с разъяснениями что не так и актив был бы больше (хотя с качеством кода...).
P.S Так же есть мнение, что автор солгал об стаже и начал разрабатывать продукты недавно (6 месяцев назад), либо он 17 лет "учит всё завтра".
В моей практике собеседований php специалистов я постоянно сталкиваюсь с СV людей у которых 8-12 лет опыта, претендующих на Senior-позиции, но при этом они не могут перечислить даже пары принципов ООП. Обычно у всех подобных кандидатов довольно схожий опыт работы, это фриланс и долгое пиление «в одного» всяких недосайтов. Они ни когда не сталкивались с настоящими проектами и тем более не видели примеров хорошо написанного кода. По какой-то причине они упорно не выделяют время на развитие, ни профессиональное ни даже на банальное повышение уровня английского. Порыв написать что-то свое это очень хорошее рвение для подобного рода «спецов», так как это может позволить им преодолеть огромные пробелы в знаниях.
Уверен, многих тут тригернуло на написание комментариев сильное несоответствие кода и заявленного опыта, но как я и сказал, сейчас это распространенная проблема (интервьюеры не дадут мне соврать). Думаю человек принадлежит к упомянутой выше касте, однако, скорее всего, автор этой статьи не старше 16 лет и таким образом, просто пытался казаться «старше».
Я до сих пор с ужасом думаю, сколько времени потратил впустую, сидя на таком вот колупании в песочнице. Когда фактического развития не было вообще. И наоборот — насколько резко пошло развитие после того как присоединился к команде, работающей над серьёзным проектом.
Так стоп, мне было недавно 16, мой опыт - 1.5 года из которого 0.5 я профилонил в шараге (потому что знаний нихрена не дают). Как так получается, что люди которые 17 лет сидят и пишут плагины для ВордПресс ни разу не задумывались о том, что их код может быть плохим? За мое время изучения (напоминаю 1 год) PHP я успел пощупать Wordpress, Opencart, Laravel, Symfony, CodeIgniter, а тут за 17 лет ничего не сделать? Пожалуй теперь моя самооценка слегка поднимется, однако я не представляю как можно столько времени чаи гонять. Я уверен, что это глобальный троллинг.
Вопрос тут не в "пощупать", а в том, что осталось в руках после ощупывания. А то получится как в том анекдоте, "Я знаю каратэ, самбо, айкидо, дзюдо, ушу и много других страшных слов". Сам по себе инструмент тоже роли не играет — на том же ларавле сейчас армия обезьян, не уступающая орде ворпрессников.
Дело тут скорее в круге и уровне задач. Если твоя работа не ставит перед тобой постоянно новые задачи, новые испытания; если для работы хватает одних и тех же полученных когда-то знаний — то нет и развития.
Причем развитие программиста происходит в первую очередь на сложных проектах. Только на сложном проекте начинаешь понимать, к чему все эти страшные слова — SOLID, DI, DDD, TDD и прочие.
К примеру, только поработав над большой и сложной системой, сможешь понять, почему традиционный ларавель-стайл не подходит для такого уровня задач. И что хотя на Ларавле и можно писать нормально, но смысл тогда теряется — проще тогда уж сразу делать на Симфони.
Тоже выскажусь, пожалуй,
Ну для начала, конечно же, благодарность автору за проделанную работу, какую, пока не акцентируем внимание, все же было потрачено время и на коддинг, и на документацию и на пост, поэтому, автор - вы молодец, хотя бы потому, что не сидите на диване и что-то творите.
Теперь по существу,
я не против чего-то нашего "отечественного", но и игнорировать существующие, проверенные временем современные практики в программировании, тоже нельзя. Нет смысла изобретать по новой велосипеды в виде классов Session, Request, и тд. и тп., ну т.е. если вы туда копипастите реализации Symfony и других фрейморков, то куда ни шло, хотя задал бы очевидный вопрос, зачем? если можно через composer получить готовый, автообновляемый код... А если вы пишите что-то свое, да еще и в одиночку, остается лишь надеяться, что через много лет оно станет идеальным для текущего времени, но совершенно устаревшим для того времени, к которому код будет дописан до конца.
Я все же надеюсь, что вы найдете помощников, одному кодить неправильно, нужен код-ревью, взгляд со стороны, архитектурные решения в одиночку не должны приниматься, и еще я бы еще обратил внимание на использование линтеров, точнее их "неиспользование", отсутствие тестов - если вы в начальном этапе - лучше сразу пишите тесты, когда кода станет тонна, покрывать тестами замучаетесь. Вы должны понимать что любое "незначительное" изменение может сломать уже существующий функционал, поэтому о важности тестов говорить я думаю не стоит.
Поэтому, если у вас есть план, роадмэп, время и силы и огномное желание довести до конца начатое, то я желаю вам удачи в вашем нелегком деле.
Я не собираюсь подбирать слова, говорить что автор молодец, что потратил время, и что нужно это допилить. Это просто невероятный шлак, это нужно выкинуть и читать много книг по разработке, практикам, паттернам.
Я много слышал о том, что в нашей стране отечественные проекты принимаются плохо. Но это не так. Есть много примеров web-разработок, я не буду их здесь называть, которые востребованы у нас. Ими пользуются. И не потому, что «партия распорядилась», а потому что они действительно нравятся людям.
А знаете почему не принимается? Потому что пишут шлак абы как, лишь бы освоить деньги, получить признание. Вот и тут так же. Вы выкатили в обозрение, в 2022 году, людям сведущим в разработке, вот этот код уровня CMS 2008 года (и то, некоторые писали в то время в разы лучше). И что Вы ждете, что люди побегут ЭТО использовать?
Потом спрашивают, почему слово "отечественное" ассоциируется с чем-то очень плохо сделанным. (и не стоит путать "отечественное" и "советское").
Что дальше, переизобретаем BolgenOS?
О, вот и в 2022-гом году появился на хабре новый фреймворкописатель на PHP 5.2 из 2008-го года :)
Невозможно без улыбки читать такие статьи :)
Какие всё мамкины командиры. Подумаешь php. Зато своё, кто то в это душу вкладывает и к тому же один
Хотел бы поблагодарить всех за комментарии и примеры. Они были крайне полезными. Начал рефакторинг кода. Конечно, дело это не быстрое, развивать буду постепенно.
В telegram канале https://t.me/isengine выкладываю оперативную информацию. Также там есть чат. Приглашаю всех, кто заинтересовался проектом.
Так как это наша, российская разработка, я очень внимательно отношусь к поддержке кириллицы в частности и к поддержке мультиязычности в общем.
Остаётся только пожелать удачи автору в освоении понимания таких понятий как “framework” и “CMS”, чтобы в будущем мы наблюдали как текущий «CMS-фреймворк» перерос в что-то одно.
Почитав несколько постов в телеграмм канале заметил, что автор хочет всё-таки отойти от концепции “CMS” и двигаться в сторону “framework”, что не может не радовать.
А вообще, в целом, будет интересно наблюдать за процессом развития данного продукта. Ибо таких активных разработок в таком ключе сейчас не встретишь :)
Автору желаю ещё раз удачи и терпения, а в будущем возможно и прозрения.
в мире php есть популярные фреймворки, хотелось бы начать с подробным обзором почему они не устроили вас. без этого статья выглядит как вода.
сам в свое время тоже писал свой фреймворк, очень круто в плане развития. Сейчас понимаю, что хорошо, что я его почти не использовал.
PHP фреймворк отечественной разработки