Serhii (85.03) увеличил карму remote_adm (4000.46)

Сейчас еще дойдем до того что хорошо бы вынести всё это в параметр сниппета чтобы можно было разные пути указывать. ((%

вот было бы не плохо

вот было бы не плохо

Дык, Вы сниппет пишите, вот и добавьте туда подобный функционал. (:

+ Спасибо, то что искал.

И когда решат отказаться от @B_FILE, то придется переделать сниппет. ((%

та я вот не могу понять как с блейдом работать отдельно от ядра

штука то мощная и удобная

та я вот не могу понять как с блейдом работать отдельно от ядра

Не очень понятно что Вы там пытаетесь сделать. Смысл сниппетов в целом теряется когда есть контроллеры и пакеты. Возможно, просто не туда идете. В сниппете, обычно, не привязывают какой-то отдельный путь к шаблону, а выносят в настройку чтобы можно было использовать и дальше. Ну и сам сниппет, в рамках Эво, просто обрабатывает данные выдавая результат и привязка внутри сниппета к какому-то шаблону частично используемому по сути чанку как-то немного странно выглядит. Может, опять же, не всё понятно что делаете.

Может действительно не туда иду.

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

В контроллерах то понятно, но хочется сделать так, чтобы установил и завелось

вот пример мультияза для этого дела https://github.com/Seiger/seigerlang

Вне ядра но средствами ядра это так https://github.com/webber12/evocms-user/blob/master/src/Services/SendForm.php#L39

И там внутри хоть чанк b_file, хоть code

В теории, конечно же😁

Странно. Я думал внутри там везде блейды и вьюшки.

Внутри чего именно? Внутри своего можно делать как угодно :)

Ну в твоём пакете. Типа везде новый стиль, блейды

Зачем урезать стандартный функционал эво, который парсит и блейды и твиги и обычные коды/файлы только до блейда? У меня не было никогда цели подрочить на блейд, я же вырос в рамках эво, где 10 разных вариантов сделать одно и то же ))

И то верно

Тем более, что он и нужен то в одном месте: распарсить reportTpl для формы

Остальное там все возвращается в виде responce()->json()

Т.е. это просто пример, как штатными средствами трешки парсить чанки своих сниппетов :)

https://github.com/webber12/evocms-user/blob/master/src/Helpers/Response.php#L19

И не спрашивай, зачем для этого отдельный класс 😁😁

Да хозяин-барин... Я бложег доделал по системе этой, когда в 1 контроллер 1 метод. Итого этих контроллеров там как говна за баней. Но зато какая-никакая структура и повторяемость

Ну хз, насколько я понимаю, основная мощь ларавеля должна крыться в сервис-контейнерах, которые подключаются через сервис-провайдеры. А нахуевертить 2 вагона контроллеров на голые роуты - так себе разработка на ларавеле ))

Наверно это уровень сложности где-то между сниппетами aDate и alterTitle по их шкале ))

Хотя хз, завоза вагона уникальных великолепных дополнений на ларавеле мы так и не дождались же)) может их и вообще не существует, раз никто не видел

Ну хз. У меня там всякое говно типа отдельных реквестов и целый 1 сервисный класс.

Да че болтать) https://github.com/0test/blog.localhost открыл

Вдруг кому и правда бложег нужен.

Вдруг кому и правда бложег нужен.

+ блог готов, принимайся за магазин, и чтоб сразу с опциями, мультивалютами и кабинетом 😁

webber_12 (6894.47) увеличил карму remote_adm (4083.49)

+ блог готов, принимайся за магазин, и чтоб сразу с опциями, мультивалютами и кабинетом 😁

А магазин есть...

Да че болтать) https://github.com/0test/blog.localhost открыл

Нет, не открыли. (:

Я считерил и сделал модели и их связи также, как сделано у Михаила

Нет, не открыли. (:

"This repository is currently public."

"This repository is currently public."

Вот сейчас да. (:

У меня гит вообще какое-то время не работал толком. Блокировки что ли были, хз.

Майкрософт же, классика. ((:

Да вот думаю в новом году на работе может на gitlab попробовать.

У меня там два сайта просятся прям — "сделай на дев-прод, а то умрём".

А там по урокам было столько контроллеров?)

Да. 1 действие — 1 контроллер)

Обычно же одна сущность - один контроллер PostController, а создание, редактирование, показ и т.п. разруливать методами

Т.е. таблица posts, к ней модель Post и контроллер PostController

И типа если я рабтаю с моделькой коммента - то вот тебе по одной штуке на показ, апдейт, удаление и т.п. Ну вот такой метод у человека. Также точно оно в роутах и вьюшках. И вцелом получается логично, не надо придумывать названий. Просто копировал, вставил - и ты уже вместо коммента с тегом... Да, можно и в 1 файл. Мне тоже как-то дико казалось, но решил не выёбываться и сделать как люди говорят.

Ещё чуть-чуть и всё-таки понравится шаблон ADR. (;

Хз, сколько видел гайдов по ларе везде обычно шло posts/Post/PostController, users/User/UserController и т.п.

Тут какой-то свой метод ))

Мало того... Если заглянуть в контроллеры поста, то они унаследованы от базового, в который отдаётся файлик сервиса, и уже в этом файле методы работы с постом. Хер докопаешься, где что лежит.

Я не знаю, зачем так. Предполагаю, что это подход для разработки чего-то такого мега-большого, где, скажем, на создание поста (условно) допом идёт гора всякого. И чтобы не совать всё в 1 файл, делают так.

Хз, по ощущению похоже, что где-то кто-то кого-то наебывает ))

Структура, чтоб для админа был отдельный контроллер редактирования поста выглядит странновато )

А чего эт? Своя валидация, то-сё.

Ну если заюзать. У меня там вроде 1 реквест файл.

Ну так есть реквест к контроллеру Post, в методе authorize() проверяешь, может ли его чел слать, в методе rules() проверяешь, насколько он валидный - и в бой

Я так пока мыслю ))

Ну так це не образец. Или образец, но образец именно того подхода.

Сейчас окажется что и в ларавеле нет правильного прямого пути, а есть хуилиард обходных костылей 😅😅 и наша жизнь никогда не будет прежней )))

Ну как бы уже ответ "да"

Однометодные контроллеры, ресурс-контроллер, просто "хуяк и это контроллер".

Ну так це не образец. Или образец, но образец именно того подхода.

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

Ну я предыдущий проект так и делал. Сейчас возвращаюсь и думаю, где что лежит... А тут вроде хотя бы структура ясная, ты вот с первого взгляда понял, что за херня и почему её куча))

Дальше мысли попробовать это дело поженить хотя бы в админке с vue. Чтобы прям летало нафиг. Но это нужна ещё прекрасная неделя без детей, с оливье и новым жёстким диском...

Все не читал, но таким же болею последнюю неделю

В архитектуру подался, а там ddd, cqrs, event sourcing, слоистая архитектура и куча всего вокруг

В архитектуру подался, а там ddd, cqrs, event sourcing, слоистая архитектура и куча всего вокруг

А по факту всё-равно часто на это забивают. Как-то чем больше погружаюсь в проекты сторонние то всё больше и больше замечаю забивания на все эти структуры и прочие вещи

А по факту всё-равно часто на это забивают. Как-то чем больше погружаюсь в проекты сторонние то всё больше и больше замечаю забивания на все эти структуры и прочие вещи

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

Так что тут вопрос желание писать красиво упирается в действительность и $ в итоге

Дык, так всегда и есть. Нет смысла тратить время и деньги там, где это никому не нужно, тем более это может усложнить проект и его поддержку. Шаблоны проектирования нужно знать для того чтобы понимать почему в проекте применили тот или иной подход к разработке и как двигаться дальше. Это просто "общение" в котором так же не все однозначно, т.к. многие шаблоны каждый разработчик понимает по своему. (%

Дык, так всегда и есть. Нет смысла тратить время и деньги там, где это никому не нужно, тем более это может усложнить проект и его поддержку. Шаблоны проектирования нужно знать для того чтобы понимать почему в проекте применили тот или иной подход к разработке и как двигаться дальше. Это просто "общение" в котором так же не все однозначно, т.к. многие шаблоны каждый разработчик понимает по своему. (%

Так появился битрикс

Так появился битрикс

Так много чего появилось. ((% В том же ларавель часть людей называют шаблон служб (service) - шаблоном шлюза (gateway). По сути просто передавая данные из контроллера в "шлюз" и обрабатывая их там выдавая в контроллер результат. В ларавель очень часто используя шаблон ADR исходят из того что Respoders это отдельный дополнительный класс в котором происходит вся логика презентации. При этом как-то не особо акцентируют внимание на Domain, он как бы "сращивается" с Respondres. В том же slim когда использую ADR больше уделяю внимания Domain и вся магия происходит в Service отделяя Repository используя его только как хранилище данных. А сам Responder делаю универсальным без выноса в отдельный класс для каждого действия. Принцип один и тот же, шаблон один и тот же, а подход - разный.

Вот в том OOP часть говорят про SOLID и как часть этого о Принципе единственной ответственности (SRP), а потом ругаются на "большое кол-во" файлов и лепят в один контроллер кучу методов создавая "толстые контроллеры" с огромным кол-во обязанностей. Не говоря уже о наследовании от базового контроллера с кучей обязанностей. (%

Все верно сказано

Привет! Подскажите пожалуйста, почему такая конструкция не работает на странице "спасибо за заказ" [[include? &session=shk_order_id]] - работает [[include? &session=shk_order_price]] - не работает Шопкипер 1.3.6RC Order management Версия EVO 1.4.11

Привет! Подскажите пожалуйста, почему такая конструкция не работает на странице "спасибо за заказ" [[include? &session=shk_order_id]] - работает [[include? &session=shk_order_price]] - не работает Шопкипер 1.3.6RC Order management Версия EVO 1.4.11

а что там в сниппете include?

А там шаблон проектирования "спагетти-код". (:

А там шаблон проектирования "спагетти-код". (:

тогда ответ - потому что гладиолус)