O-Planet Apr 17 at 08:16

Я потратил 10 лет на создание легкого PHP фреймворка для разработки WEB-приложений

Medium

5 min

10K

PHP * Open source * DevOps * JavaScript * GitHub *

Review

From sandbox

+12

Comments 28

Vladzimir Apr 17 at 10:01

По концепту похож на https://github.com/atk4/ui но с более низким порогом вхождения и без зависимостей и сильной связанности.

KoIIIeY Apr 17 at 10:18

Честно говоря, не удобно выглядит. Хаки аж в примере, кастомизации 0, прям пыха 20+ лет назад

O-Planet Apr 17 at 12:05

Ахах. Ну я еще тот динозавр, да. А какой может быть вариант без хаков? Вообще, с ними все предполагалось просто. У любого метода есть три хака: check - выполнять или нет, before - редактировать параметры, on - после выполнения. Если есть метод obj.morkovka(), то можно определить шесть хаков: три клиентских, три серверных. checkmorkovka(), beforemorkovka(), onmorkovka()

KoIIIeY Apr 17 at 12:23

В том и дело, что для простого сайта слишком сложно, а для сложного слишком просто

O-Planet Apr 17 at 12:59

Для просто сайта хаки и не нужны, думаю. Это ж для реализации бизнес сущностей: справочников, документов, регистров. Я занимаюсь WEB-приложениями в основном, не сайтами.

JerryI Apr 17 at 12:28

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

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

O-Planet Apr 17 at 13:01

Что можно предлдожить по хакам? Я сейчас портирую жэто на node. Получается интересно: весь клиентский код на объектах. Один язык, одни переменные. Может, просто не употреблять слово хак?:)

JerryI Apr 17 at 21:44

Ну вот здесь скажем, неочевидно что происходит, как будто в основном фреймворке не сделали для этого свойство или фичу

// Проверки перед окончанием редактирования строки $subtable->method('checkrowsave(values)', <<

dmitriylanets Apr 17 at 13:02

Так себе идея. Пробовал аналогичное решение лет так десять назад, но в итоге остановился на таблицах и формах для админки максимум. + Связи с бд с помощью репозитория.

Для фронта лучше twig или rest api. Объектную модель для фронта слишком тяжело поддерживать так как этот слой меняется чаще других и используется фронтендером.

MyraJKee Apr 17 at 13:04

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

Полезно разве что может для каких-то небольших админок. Но да там и решений всяких тоже полно похожих.

Vladzimir Apr 17 at 13:06

Каких например? Большинство завязаны на определенный фреймворк и чаще всего монструозны.

MyraJKee Apr 17 at 14:22

Согласен, большинство завязаны на какой-нибудь фреймворк.

O-Planet Apr 17 at 23:48

Ну, я во фрилансе уже 20 лет. Приходится в одиночку делать большие проекты по типу CRM с нуля или WMS. Как правило, сроки ограничены. Поэтому и задался этим вопросом: как быстро ваять WEB-приложения, не раскидывая логику по разным файлам и средствам разработки.

anagamin Apr 18 at 16:50

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

Поэтому я не понимаю удобства Blade и т.п.

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

P.S. во фрилансе тоже 20+ лет.

Lokai Apr 17 at 14:52

Думаете, идея бредовая?

Да

ncix Apr 17 at 18:42

Респект, коллега!

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

Сам давно использую похожие конструкторы. И тоже переписал их с PHP на node

O-Planet Apr 17 at 23:44

Да, слоистая архитектура в WEB, по сути, атавизм из 90-х. Берусь утверждать, что в ближайшем десятилетии от нее отойдут. Переход на классы - один из вариантов.

ncix Apr 17 at 18:46

А как обстоят дела с:

Общими и колоночными фильтрами и сортировками
Связями между таблицами, выпадающими списками (желательно с поиском)
Правами
Постраничный вывод таблиц или динамическая подгрузка?
Редактирование сущностей прямо в таблице без обновления страниц

O-Planet Apr 17 at 23:38

Все это рализовано, конечно. На гитхабе полная документация с примерами.

O-Planet Apr 17 at 23:40

Вижу, что многие комментаторы просто поленились заглянуть на гитхаб.

BlackJericho Apr 17 at 23:52

Зачем отказываться от тегов ,если с ними нагляднее и куча инструментов для верстки? Зачем мне строить разметку в php если современный фронт собирается и хранит шаблоны в себе и строится через компоненты/модули??? А даже в классическом MVC опять же я и так работаю с классом в чем проблема? Более того как часто в разных фреймворках приходилось извращаться и патчить какие-то компоненты, которые атрибуты какие-то не так как надо ставили или вообще не ставили, а тут целый фреймворк, где придется сражаться с тем от чего наоборот мы бежим, скинув на react или vue. Тут что не страница чуть сложнее чем параграф с заголовками, то выйдет целая битва с каким-нибудь кривым data grid или формой. И не дай бог, что бы в эту хреноверть еще какой сторонний js компонент вкорячивать. Но как говорится чем бы дитя не тешилось. Просто от себя я никогда этот фреймворк не потащу ни в какой проект, но за старания 5.