JohnCMS | Разработка следующей версии

Тема закрыта
35.72K
.
╭∩╮ (`-`) ╭∩╮
# Simba (08.11.2019 / 18:39)
То что оно тянет за собой это понятно. Оно лежит там в папке vendor и никому не мешает и используется только если сам будешь использовать.
Можно заюзать другой инструмент, но он должен быть хорошо до
Тут да.
Когда система относительно гибкая (к чему мы стремимся), можно использовать инструменты, которые ты любишь. Никто тебе не мешает написать к примеру какой-то модуль на Ларавеле, при этом вписав его в Джоновский API.
НО!
В оф. дистрибутиве надо стараться избегать подобной ереси.
Одно дело сторонний модуль, что ты ставишь. Там автор модуля сам хозяин и делает что хочет.
И другое дело дистрибутив движка, в котором должны быть какие-то стандарты кодирования.
.
Hey guys! Finally I'm gonna change status!?
Simba, Да я то может и составлю, а кто попроще?))
.
╭∩╮ (`-`) ╭∩╮
Или Ларавель делается основной платформой Джона, тогда выпиливаем Зендовские компоненты и по максимуму юзаем удобства Ларки.
.
Hey guys! Finally I'm gonna change status!?
AlkatraZ, Убить джон никогда не поздно))
.
Кадило крутится, лавэха мутится
# kantry (08.11.2019 / 18:43)
А я кстати как то прелагал нативную библиотеку goDB вполне себе доходчивая для начинающих И к тому же на встроенном в php драйвере.
У них в документации написано
То есть, библиотека той же ниши, что и PDO.

Нахрена она нам если у нас и так PDO?
.
Hey guys! Finally I'm gonna change status!?
Simba, А я и предлагал, когда вопрос о pdo стоял,.. ну не достаточно моего интуитивного авторитета, что бы продвинуть, то что в общем то сами разработчики php предлагают
.
Кадило крутится, лавэха мутится
# AlkatraZ (08.11.2019 / 18:43)
В оф. дистрибутиве надо стараться избегать подобной ереси.
Одно дело сторонний модуль, что ты ставишь. Там автор модуля сам хозяин и делает что хочет.
И другое дело дистрибутив движка, в котором дол
Ну в этом случае получается надо изобретать велосипед заново только потому, что в существующем пакете есть что-то лишнее хоть оно и не используется...
.
╭∩╮ (`-`) ╭∩╮
Добавлено: 08.11.2019 / 19:10
Я к тому клоню, что если уж юзать компоненты Ларавеля, так по полной, включая транслятор и контейнер. У нас все равно, функции перевода отдельные _t() _p() переделать их недолго. По всей системе ничего переписывать не придется. Так же с контейнером, мне кажется или его можно будет заюзать сразу, или же написать небольшую PSR обертку.

Это в том случае, если собираешься идти по пути ларавеля.

Добавлено: 08.11.2019 / 19:24
Да, и шаблонизатор тоже тогда ларавелевский нужен.
Plates придется выпиливать.
.
Кадило крутится, лавэха мутится
# AlkatraZ (08.11.2019 / 19:24)
Я к тому клоню, что если уж юзать компоненты Ларавеля, так по полной, включая транслятор и контейнер. У нас все равно, функции перевода отдельные _t() _p() переделать их недолго. По всей системе ничег
Не вижу смысла особого юзать функции перевода и шаблонизатор. У нас это уже и так есть, а тянуть эти пакеты с ещё кучей зависимостей нет смысла.
Нам нужна только база данных и всё. То что у них нечищенные от лишнего зависимости пусть остается на их совести гг. Может они в дальнейшем почистят и станет всё хорошо )
.
╭∩╮ (`-`) ╭∩╮
Щас глянул зависимости Ларавелевского роутера, аж матом от испуга ругнулсо
https://github.com/illuminate/ ... .json
Всего: 1376
Кураторы: AlkatraZ