Comments 86
А если серьёзно, то больше всего порадовало наличие в проекте composer.json. То есть автор как бы в курсе, что это такое, но при этом реализации i18n, autoloader, acl, взаимодействия с бд и всех остальных фишек, описанных в самой статье сделана вручную, при чём далеко не самым лучшим образом.
Стоит ещё отдельно спросить про то, зачем, собственно, там autoloader, если в проекте вообще нет ООП?
но при этом реализация i18n, autoloader, acl и вот всех остальных фишек, описанных в самой статье сделана вручную
Целью проекта был минимализм. О каком минимализме может быть речь, если для установки фреймворка потребуется тянуть зависимостей весом в десяток раз больше, чем сам фреймворк? ) Другими словами, плагины, идущие в комплекте с фреймворком это минималистичные решения для распространенных инфраструктурных задач. Если же вы задумываетесь о подключении какого нить Zend-i18n, то я бы посоветовал еще раз подумать об использовании другого фреймворка.
Стоит ещё отдельно спросить про то, зачем, собственно, там autoloader, если в проекте вообще нет ООП?
Во фреймворке нет ООП, но это не значит, что вы не можете его использовать в своих модулях, ведь так? Варианта два:
- Либо используйте composer autoload generator, и тогда просто поключайте vendor/autoload.php в качестве плагина
- Либо, если не хотите composer, но хотите использовать ООП (собственные классы для каких либо целей), используете этот плагин
Возьмём тот же i18n. Как поведёт себя ваш фреймворк, если в строке будет 2 переменные с плюральной формой? Что делать, если нужно вставить подстроку вроде "Привет {username}"?
Как поведёт себя ваш фреймворк, если в строке будет 2 переменные с плюральной формой?
Можно примерчик такой строки?
Что делать, если нужно вставить подстроку вроде «Привет {username}»?
Скорее всего решение будет будет каким то таким:
<?= i18n('hello') ?> <?= $currentUser->name ?>
Поймите, фреймворк минималистичен, но если вас не устраивают встроенные плагины, то подключить сторонние библиотеки не составит вообще никакого труда. Если вам интересно, могу привести пример генерации страниц сайта через markdown с использованием стороннего пакета.
Можно примерчик такой строки?
У вас {n} друзей и {n} подписчиков.
Скорее всего решение будет будет каким то таким:
<?= i18n('hello') ?> <?= $currentUser->name ?>
Ожидаемо. Но если рассмотреть чуть более сложный кейс, когда между языками подстановка может двигаться, то окажется, что такое решение не жизнеспособно:
en: {username} profile
uk: Профіль {username}
vi: Hồ sơ của {username}
be: Профіль {username}
pt: {username} perfil
ru: Профиль {username}
У вас {n} друзей и {n} подписчиков.
У вас <?= i18n_plural($n, '%d friends') ?> и <?= i18n_plural($n, '%d subscribers') ?>
Ожидаемо. Но если рассмотреть чуть более сложный кейс
<?= sprintf(i18n('profile %s'), $currentUser->name) ?>
Вообще это не про данный фреймворк, а скорее про интернационализацию в целом.
Я просто тонко подвожу к той мысли, что подобные проекты скорее всего эффективно могут быть использованы только их авторами. Публикация подобных проектов на хабре как-то возвращает в давние года развития PHP и мешает поверить людям в то, что на PHP уже давно можно писать гораздо более серьёзные проекты.
На хабре любят тонко подводить к определенным мыслям, бегло читая то что над катом. Зная это я сразу добавил статью в соответствующий хаб ;)
Вы зря беспокоитесь о репутации PHP.
на PHP уже давно можно писать гораздо более серьёзные проекты
Вы зря беспокоитесь о репутации PHP.
Зная это я сразу добавил статью в соответствующий хаб ;)
Я сейчас напишу какую-то дичь, а потом буду орать "it's a prank, man, it's a prank!".
а потом буду орать
Не потом, а сразу. В «ненормальном программировании» статья была с момента публикации.
Не, я про то, что, как мне казалось, в тег "Ненормальное программирование" попадают частично юмористические статьи, либо же статьи с крайне "альтернативным" подходом к решению банальных задач. Ваша же задача была решена уже несколько сотен раз, в том числе и на хабре и прикрываться хабом ненормального программирования как-то… неправильно.
статьи с крайне «альтернативным» подходом к решению банальных задач
Этот фреймворк примерно из этой категории. Понимаете, сегодня в среде программистов такие настроения: «global в коде? Сжечь его!» — учитывая такую реакцию, я сразу огородился от такого рода критики соответствующим хабом )
Понимаете, сегодня в среде программистов такие настроения: «global в коде? Сжечь его!»
Возможно (но это не точно), это связано с тем, что люди уже поняли, как легко и быстро писать на PHP плохой код и жаждят зрелищ в лице качественных и интересных решений, а не очередного решения со всё теми же "хорошо горящими" решениями, вроде использование глобальных переменных, прямого чтения из $_GET, явных include, отсутствия тестов или хотя бы шансов на них и так далее.
Жаждущим людям советую приглядеться к таким решениям, как Symphony и Zend. Новичкам же, и людям, желающим побыстрому набросать простой сайт — SimplePage вполне себе вариант.
Да, вы легко можете выстрелить себе в ногу с его помощью, потому либо учтите это, либо будьте достаточно опытным чтобы этого не сделать.
Да, вы легко можете выстрелить себе в ногу с его помощью, потому либо учтите это, либо будьте достаточно опытным чтобы этого не сделать.
Если же вы задумываетесь о подключении какого нить Zend-i18n, то я бы посоветовал еще раз подумать об использовании другого фреймворка.А чем вам gettext не угодил? Вы же написали свой велосипед, пусть и минималистичный, а ведь можно было его вообще не писать, взяв готовое решение «из коробки».
Только недавно была статья про очередной фреймворк...
Но явно не было статьи про такой хороший фреймворк, как этот, ведь правда?
Чем дальше я «погружаюсь», на основе своего ли опыта или по отзывам, в т.ч. и на Хабре, тем больше склоняюсь к такому мнению:
- Symfony — хорошо
- Laravel — неплохо
- Yii — с пивом покатит
- … — что это было?
А где в этом списке Zend?
Я не писал на нём.
Ну вы и на моем фреймворке не писали, но вывод ведь какой то сделали, что вам мешает сделать вывод и о Zend?
Я сделал вывод, что писать на обоих не буду. Для совсем простых сайтов есть WordPress, для чего-то сложного — Symfony или Laravel.
Так WordPress это CMS, а не фреймворк
Я в курсе)
А что если сайт совсем простой, но выходит за рамки возможностей конкретной CMS?
Zend всё ещё обрабатывает запрос, подождите.
зачем, autoloader, если в проекте нет ООП
А должно быть ООП головного мозга? :)
del
UFO just landed and posted this here
<sarcasm>Потому что PSR-7 - это не минималистично</sarcasm>
Если вас очень беспокоит психологическое состояние котят, рекомендую задуматься об Zend-Expressive в качестве средства для быстрого прототипирования (и не только).
Возьмём тот же i18n. Как поведёт себя ваш фреймворк, если в строке будет 2 переменные с плюральной формой?
как можно спорить с человеком который в одной строке написал два одинаковых по смыслу слова? для особо не понятливых «плюральной» = «2 переменные». Не используйте непонятные слова глупо выглядит. А так фреймворк по минимуму решает задачу «получение — отображения данных» значит имеет смысл быть. А писать 10 классов, с использованием патернов программирования для hello world! как минимум глупо.
UFO just landed and posted this here
Архитектурой
UFO just landed and posted this here
Почему вы так считаете? Во фреймворке заложена рекомендованная архитектура. Сводится она к декларативной конфигурации страницы, последующей обработки деклараций, выполнения дополнительной логики и шаблонизации.
UFO just landed and posted this here
Мне кажется вы путаете понятие архитектуры с понятием «модная архитектура», а include('../sp.php') просто немного залил вам граза кровью ) Во фреймворке есть архитектура и я ее описал в предыдущем комменте
UFO just landed and posted this here
Я вам указал на архитектуру проекта, а вы мне говорите, что это структура и не сумев аргументировать свое мнение, пытаетесь съехать на том, что я не воспринимаю «обоснованную» критику )) На хабре от года к году все веселее и веселее )
UFO just landed and posted this here
Я привык к диаграммам последовательности, потому, если вы не против, изображу на ней:
UFO just landed and posted this here
прилетает прямиком во вьюв
Не во вью, а в «контроллер страницы» (есть такой паттерн по Фаулеру), который декларирует начальные условия обработки.
потом есть какой-то компонент SP
Это сам фреймворк.
который детально описывает что он мержит 2 конфига (ах как сложно)
Вы любите, чтоб все было сложно? )) На деле он расширяет декларацию страницы общей декларацией приложения.
зато всю обработку реквеста лаконично описывает одной стрелочкой run (run чего? бегун завёлся в коде?)
А он больше ничего и не делает по сути, собирает декларацию, передает управление плагинам (если необходимо) и буферизирует вывод.
Потом в роботу вступает какой-то плагин (какой?)
Это уже решает контроллер страницы, а не фреймворк.
данные никуда не отдаёт
Верно, данные не отдаются, плагины работают через декларации. Фреймворк то декларативный.
Честно говоря, диаграмма у вас так себе
Зато столько вопросов сразу решает ) Вы еще забыли про стрелочку postRun, она очень важна.
UFO just landed and posted this here
Вообще контроллер не имеет имени, там просто файл вида articles/view/index.php, я в диаграмме его так назвал, чтоб возможно было отличить контроллер страницы (который в том числе содержит View), от остальных частей системы.
Нет, запрос принимает и обрабатывает контроллер страницы, не фреймворк. Вообще я не люблю термин «фреймворк», но зачем то его использую. Я считаю что это не просто библиотека, так как он имеет архитектуру. Другими словами в моем понимании фреймворк = библиотека + архитектура.
Фреймворк занимается буферизацией, чтоб было возможно не только вынести логику буферизации из контроллера страницы, но и для реализации плагина layout, который оборачивает вывод.
Нет, контроллер не дергает плагин, контроллер декларирует фреймворку, какие плагины ему нужны для обработки запроса. К примеру у вас есть страница «О проекте», там не нужен плагин для работы с БД, потому контроллер не запрашивает подключение этого плагина, а вот контроллер страницы «Статья» уже запрашивает, так как ему нужно обратиться к базе данных.
Нет, запрос принимает и обрабатывает контроллер страницы, не фреймворк. Вообще я не люблю термин «фреймворк», но зачем то его использую. Я считаю что это не просто библиотека, так как он имеет архитектуру. Другими словами в моем понимании фреймворк = библиотека + архитектура.
Фреймворк занимается буферизацией, чтоб было возможно не только вынести логику буферизации из контроллера страницы, но и для реализации плагина layout, который оборачивает вывод.
Нет, контроллер не дергает плагин, контроллер декларирует фреймворку, какие плагины ему нужны для обработки запроса. К примеру у вас есть страница «О проекте», там не нужен плагин для работы с БД, потому контроллер не запрашивает подключение этого плагина, а вот контроллер страницы «Статья» уже запрашивает, так как ему нужно обратиться к базе данных.
UFO just landed and posted this here
Вы совершенно правы, во фреймворке нет «единой точки входа», все как в бородатые 2000е, каждый файл — контроллер.
Если говорить о контексте и разделении ответственности, то очень коротко можно сказать так — за обработку запроса и возврат ответа отвечает конкретная страница, фреймворк же просто предоставляет вспомогательные инструменты для этого. Это не классический MVC и даже не ООП с разделением ответственности и вызовами, это один процедурный код, отвечающий за обработку запроса через декларации.
По поводу гибкости системы, я пошел по пути минимализма не случайно. Идея в том, чтобы фреймворк был настолько простым, чтобы не требовать изменений в своей архитектуре или интерфейсах вовсе. Да и он нацелен на прототипирование, о какой изменчивости вы говорите? )
Если говорить о контексте и разделении ответственности, то очень коротко можно сказать так — за обработку запроса и возврат ответа отвечает конкретная страница, фреймворк же просто предоставляет вспомогательные инструменты для этого. Это не классический MVC и даже не ООП с разделением ответственности и вызовами, это один процедурный код, отвечающий за обработку запроса через декларации.
По поводу гибкости системы, я пошел по пути минимализма не случайно. Идея в том, чтобы фреймворк был настолько простым, чтобы не требовать изменений в своей архитектуре или интерфейсах вовсе. Да и он нацелен на прототипирование, о какой изменчивости вы говорите? )
UFO just landed and posted this here
Есть уже Slim и Zend-Expressive для этих целей, а ЦА у меня частично не умеет ООП.
UFO just landed and posted this here
Начну с конца )
Не беспокойтесь о репутации PHP.
Еще раз повторяю, я придерживался минимализма, о каком конфигураторе может идти речь в таких условиях? ) Да, можно было сделать все «круто» и «красиво», но посмотрите на хаб статьи.
В качестве верного направления для развития ЦА я ссылаюсь на Zend и Symphony, и другие мои поделки, это же прикладной, а не учебный проект.
Не беспокойтесь о репутации PHP.
Еще раз повторяю, я придерживался минимализма, о каком конфигураторе может идти речь в таких условиях? ) Да, можно было сделать все «круто» и «красиво», но посмотрите на хаб статьи.
В качестве верного направления для развития ЦА я ссылаюсь на Zend и Symphony, и другие мои поделки, это же прикладной, а не учебный проект.
UFO just landed and posted this here
UFO just landed and posted this here
Зачем вам исходники, есть официальная документация, ее и нужно выкурить в первую очередь.
Composer require требует composer, что явно сложнее, чем его отсутствие )
То есть чем больше зависимостей, тем лучше?
Composer require требует composer, что явно сложнее, чем его отсутствие )
То есть чем больше зависимостей, тем лучше?
UFO just landed and posted this here
Вы сильно зависите от IDE )) Ну это ваше право, конечно.
Я не претендую на хорошесть кода, я претендую на простоту в установке и использовании.
Вы понимаете что тут речь идет о прототипировании, а не о полноценной разработке? )
Я не претендую на хорошесть кода, я претендую на простоту в установке и использовании.
Вы понимаете что тут речь идет о прототипировании, а не о полноценной разработке? )
ох ты-ж… давно не видел такой жести… года с 2002-го… даже вот это выглядит куда лучше ;)
Мое решение проще )
Нахерачить код вперемешку с вёрсткой вообще без include ещё проще.
Тогда не будет архитектуры и сложнее будет работать с кодом
Так называемой "архитектуры".
UFO just landed and posted this here
Поправлю себя — тогда это будет более сложная и запутанная архитектура
Вообще — нет, «архитектура» будет намного проще, т.к. нет вообще никаких зависимостей.
Раз уж используете внешние файлы и composer — избавьтесь от include, это-же элементарно…
Раз уж используете внешние файлы и composer — избавьтесь от include, это-же элементарно…
Мне вот тоже не понятно почему автор отказался от ООП. Подсказки IDE экономят память, которую лучше загрузить бизнес логикой.
В остальном для прототопирования сгодиться что угодно. Это же фреймворк не для разработки, а чисто что бы накидать на коленке.
Но тоже не понятно, что эти байты экономить, когда для накидать на коленке годиться тот же Slim, весит он пол мегабайта, у него есть тот же самый PhpRenderer, если очень хочется использовать родную шаблонизацию PHP.
Композер это толсто? Композер это 30 килобайт.
вам же эти 30 кб не руками набивать. не грузить в какой то микроконтроллер что бы каждый байт считать, зачем такой ультра минимализм? что бы попасть в книгу рекордов Гиннесса?
Почему «хорошо» — это использовать общепринятые инструменты типа Композера и Slim?
Что бы посторонним было проще разобраться в коде вашего проекта или ваши наработок (прототипов).
но если хочется повелосипедить, то чем бы дитя не тешилось :)
В остальном для прототопирования сгодиться что угодно. Это же фреймворк не для разработки, а чисто что бы накидать на коленке.
Но тоже не понятно, что эти байты экономить, когда для накидать на коленке годиться тот же Slim, весит он пол мегабайта, у него есть тот же самый PhpRenderer, если очень хочется использовать родную шаблонизацию PHP.
Композер это толсто? Композер это 30 килобайт.
вам же эти 30 кб не руками набивать. не грузить в какой то микроконтроллер что бы каждый байт считать, зачем такой ультра минимализм? что бы попасть в книгу рекордов Гиннесса?
Почему «хорошо» — это использовать общепринятые инструменты типа Композера и Slim?
Что бы посторонним было проще разобраться в коде вашего проекта или ваши наработок (прототипов).
но если хочется повелосипедить, то чем бы дитя не тешилось :)
Sign up to leave a comment.
SimplePage: простой, декларативный фреймворк для быстрого прототипирования