Смотри тригеры группы user

Да я в коде по цепочке прошелся, не нашел ни одного эвента до самого запроса в таблице

Да я в коде по цепочке прошелся, не нашел ни одного эвента до самого запроса в таблице

Тебе не надо менять родную факторию тебе надо в самом user поменять и добавить данные

https://stitcher.io/blog/new-in-php-82

Тебе не надо менять родную факторию тебе надо в самом user поменять и добавить данные

Ну там на самом деле всё сложнее, мне не просто надо подменить данные, а надо по-хорошему в стандартном User классе заменить методы на свои, чтобы он обрабатывал данные иначе, иначе сохранял и т.д. Т.е. в бизнес логике всех компонентов этот юзер вызывается. Но придется делать по старинке, через события. Спасибо!

Ну там на самом деле всё сложнее, мне не просто надо подменить данные, а надо по-хорошему в стандартном User классе заменить методы на свои, чтобы он обрабатывал данные иначе, иначе сохранял и т.д. Т.е. в бизнес логике всех компонентов этот юзер вызывается. Но придется делать по старинке, через события. Спасибо!

Иначе сохранять не верный подход. Есть триггер до и после. В общем нет ничего не возможного со стандартной факторией

Иначе сохранять не верный подход. Есть триггер до и после. В общем нет ничего не возможного со стандартной факторией

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

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

Так не делайте дублирующий функионал. а расширяйт его. иначе если вы замените стандартный core class то все рухнет через неделю. правильное и каноничное использования ядра залог успеха. ну правильное планирование

Не, тоже поздно. Там экземпляр UserFactory создается одновременно вместе application. Прост у нас по сути юзеры берутся и хранятся на стороннем ресурсе, а на сайте только специфичные для этого сайта данные. Хотел сделать всё, чтобы выглядело нативно и чтобы бизнес логика даже не догадывалась о происхождении юзеров.

вот твой случай. если ты менишь класс исключая ядро. то как только сторонний сервис отвалится отвалится весь сайт. ведь guest - это тоже User

поэтому в таких случиях стронний сервис - это довесок. но не наоборот

Почему? В таком случае создается дефолтовый пустой юзер, как и стандартно

Если ли смысл просить разработчиков Joomla это вынести в файл конфигурации?

Если ли смысл просить разработчиков Joomla это вынести в файл конфигурации?

да напиши

некусаются

А то сам факт что это всё жестко вписано мне кажется не есть гуд

только вряд ли добавят быстро

А так бы как во взрослых фремворках гибко было бы

Попробуем-с написать

Попробуем-с написать

Ты можешь писать в joomla 5

Они специально спрашивали что делать

Да по идее это и в какой-нибуль 4.2 реализовать можно. Задача сама по себе не сильно сложная

Да по идее это и в какой-нибуль 4.2 реализовать можно. Задача сама по себе не сильно сложная

Вопрос не в сложности а в семантической версионности

Да по идее это и в какой-нибуль 4.2 реализовать можно. Задача сама по себе не сильно сложная

4.2 не вариант, там уже beta😊

Тогда 4.3 =)

А то 5 может мы ещё до второго пришествия ждать будем, помня о том сколько откладывали 4 версию)

Я за контекстом не слежу

Опять левые реакции

Опять левые реакции

не побороть

только пока забить

Если ли смысл просить разработчиков Joomla это вынести в файл конфигурации?

Ну от того что ты напишешь от тебя не убудет. Главное про аргументацию не забудь.

Ну от того что ты напишешь от тебя не убудет. Главное про аргументацию не забудь.

Ну мне кажется то что это повышает гибкость в разы на поверхности)

Ну мне кажется то что это повышает гибкость в разы на поверхности)

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

Ну мне кажется то что это повышает гибкость в разы на поверхности)

Но повторюсь участие в развитии движка в любом случае полезно. Но любые кор изменения требуют описания. Иначе заврнут даже на код не посмотрев

Просто они сделали провайдеры по аналогии как например в Ларе. А файл конфигурации как в ней же не завезли, из-за этого половина смысла теряется)

Просто они сделали провайдеры по аналогии как например в Ларе. А файл конфигурации как в ней же не завезли, из-за этого половина смысла теряется)

Главное чтобы не было как в ларе. Где про совместимость не слышали =)

Ну это следствие бурного развития, а не гибкости. Там каждый год всё меняется)

Ну это следствие бурного развития, а не гибкости. Там каждый год всё меняется)

Это следствия одного и другого. Просто смотри. Я не могу сказать хорошую вещь ты предлагаешь или нет. Пока не перерою все ядро что понять где как используется и какие последствия. В отличии от меня тот кто это написал их уже знает и имел причину не вставлять конфиг. Она может быть дурацкой а может нет.

Ну это следствие бурного развития, а не гибкости. Там каждый год всё меняется)

В общем главное не пиши. Типа "так будет гибче"

Но подать запрос стоит. Если не одобрят то хоть узнаешь почему

Ну и стоит ещё проверить сам контейнер. P.s я немного посмотрел и увидел что контейнер можно заменить целиком =)

Ну замена уже на лету - это всегда куча потенциальных проблем. Уж не говоря про кучу лишнего исполняемого кода при загрузке)

Ну замена уже на лету - это всегда куча потенциальных проблем. Уж не говоря про кучу лишнего исполняемого кода при загрузке)

Когда вы порождаете кучу абстракций, почему то лишний код вас мало заботит…

Ну замена уже на лету - это всегда куча потенциальных проблем. Уж не говоря про кучу лишнего исполняемого кода при загрузке)

Ну судя по коду лишнего там нет. А вот конфиг наоборот может вызвать не предсказуемый результат. Да и какие проблемы просто подменили в раме данные и все. Можно даже потом вернуть как было

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

Когда вы порождаете кучу абстракций, почему то лишний код вас мало заботит…

Ну это не тоже самое. При создании аппликации прогружаются вот эти полтора десятка сервис провайдера, которые тащат кучу регистраций и делают запросы в БД (например тот же юзер). А потом ты всё это сбрасываешь и делаешь по новой. По сути здесь ты практически дважды полноценно загружаешь ядро Джумлы.

Ну это не тоже самое. При создании аппликации прогружаются вот эти полтора десятка сервис провайдера, которые тащат кучу регистраций и делают запросы в БД (например тот же юзер). А потом ты всё это сбрасываешь и делаешь по новой. По сути здесь ты практически дважды полноценно загружаешь ядро Джумлы.

А ты не сбрасывай.

А ты не сбрасывай.

Ну это я про замену контейнера)

Ну это я про замену контейнера)

Ну я могу один контейнер подменить этим же изменены контейнером к примеру

Если ли смысл просить разработчиков Joomla это вынести в файл конфигурации?

нет

Ты путаешь фреймворк и cms

cms запускает то, что её нужно

нет

Ну зачем....

Если ты хочешь определить своё - пользуйся фрейворком

Мне же ещё пол часа ехать. Скучно...

Мне же ещё пол часа ехать. Скучно...

😝

Если ты хочешь определить своё - пользуйся фрейворком

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

Если ты хочешь определить своё - пользуйся фрейворком

При таком раскладе человек с большой долей вероятности предпочтёт "взрослый" фреймворк типа Лары или Симфони. Вся фишка Джумлы в том что ты можешь изначально развернуть всё как на cms, но при необходимости свободно докрутить недостающее средствами неплохого фреймворка

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

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

И отсутствие катастроф как в ларке

Когда становятся просто неподдерживаемыми

В том числе

Хм, а я сейчас понял, что в Джумле используется два контейнера

в каких-то случаях просто контейнер:

А в каких-то ещё присутствует родительский контейнер:

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

А то обратил внимание, что кладу в контейнер данные, а их в другом месте нет, потому что они в разных контейнерах

Как я понял, на каждый extension создается отдельный контейнер

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

Хм, не пойму, а есть сейчас в 4 Джумле полноценный аналог этой конструкции? $user = User::getInstance($id); Сейчас это deprecated. И вместо него предлагается использовать: Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($id); Но он при каждом обращении создаёт новый экземпляр юзера.

Помогите разобраться - на сайте по умолчанию есть куки? То есть нужно обязательно всплывающее окно с предупреждением? Или я ошибаюсь?

Помогите разобраться - на сайте по умолчанию есть куки? То есть нужно обязательно всплывающее окно с предупреждением? Или я ошибаюсь?

В России это не обязательно

Помогите разобраться - на сайте по умолчанию есть куки? То есть нужно обязательно всплывающее окно с предупреждением? Или я ошибаюсь?

Законодательно вроде этого нигде нет

Это я так понимаю раз западные делают то и мы должны

Хз. Вроде законов нет никаких

У нас даже номер телефона это не персональные данные

Пока что

У нас даже номер телефона это не персональные данные

пд если имя рядом. там выщло разяснение

пд если имя рядом. там выщло разяснение

Я отдельно про номер

пд если имя рядом. там выщло разяснение

Да и сказать то могут, а когда до судебной практики дойдёт, все не так будет

Ну может быть, я не знаю, просто судебная практика интересная штука, всякое может быть