Также чтобы ваш метод setSlugAttribute сработал, вам необходимо в request передавать slug..что не подходит для вас.
Вам необходимо посмотрить Eloquent Events.
Alexander Leonchik, попробую более детально описать текущую задачу и ответы на ваши вопросы.
Я вот одного понять не могу, вы уверенны что вам это нужно?
Да, это необходимо так как система будет расширяться на другие страны. И так же нет необходимости отображать данные из одной страны в другой (копии приложений со своими бд - как вариант).
почему пользователь Вася зарегался в РФ, приехал в Финляндию и у него уже другие данные?
Если будут свои копии приложение со своими базами данными, и будет стоять балансировщик запросов по странам, то Вася, который был зарегистрирован в РФ (данные которые хранятся в базе данных для РФ) не сможет уже зайти под своими данными из Финляндии, так как балнсировщик будет направлять его на другую копию прложения с другой бд (где нет данных Васи).
а как старые получить?
Это и является, некой, частью вопроса. Если делать разные приложения с разными бд, то чисто и красиво не получится. Что вы думаете по этому поводу?
Пример приложения:
Есть платформа на которой любой пользователь может зарегестрировать свой магазин и продавать на ней свои товары, так же есть некая страница где будут размещены все товары от всех магазинов. Покапатели зайдя на эту страницу видят все товары и могут совершать покупки.
Но вот появилась необходимость разместить данную платформу для других стран, но не хочется смешивать товары из разных стран. Необходимо чтобы пользователь зайдя в систему видел только ту продукцию и только те магазины, которые находятся в его стране.
Также пользователи не должны никак ничего не знать о том, что есть некие другие товары и другие магазины из других стран. Для них это будет просто локальная платформа для их страны.
Но если делать всё через одну бд, то как тогда мне отображать данные которые были созданы в одной стране только для этой страны? Добавлять в каждую таблицу страну и по ней фильтровать?
Wexter, и там будет хранится информация о пользователях? Тогда приложению придётся общаться с двумя бд, верно? С одной для получения информации о пользователе по токену, а со второй для получения всей остальной информации или я не прав?
Тогда надо будет добавить дополнительное поле в форму регистрации (для выбора страны), что для меня не очень уместно, так как хочется чтобы данная форма была очень простая.
Спасибо, но я смотрел это уже всё.
Я нашёл библиотеку pusher-redux и на основе её стал делать свою обёртку для laravel-echo, так как я использую именно pusher в качестве посредника для ws. Но думал, может кто-то уже делал что-то подобное и мог бы поделиться своим опытом и наработками.
я хочу сделать плагин для вордпресса к которому можно будет обращаться по конкретному роуту и если я в на другом сайте добавлю iframe то мне загрузится этот плагин с его вёрсткой, дизайном, js.
а как мне сделать доступным этот плагин по указанному роуту?
т.е. чтобы он мог быть как обычный плагин для вордпресс и чтобы я мог на другом сайте вставить iframe с определённым урлом по которому мне загрузится плагин с его стилями, js, и логикой.
sim3x
благодарю за советы, попробую ещё поискать в интернете как люди делают, а то чувствую мой вариант, который в вопросе не очень хороший, вот тот, который в ответе на ваш ответ думаю уже лучше, но чувствую, что есть ещё получше )
Есть ещё вариант использования Redis только как pub/sub. Вся основная работа будет лежать на Django, запись сообщений, уведомлений всё будет происходить в Django, но так же Django будет слать publish уведомления в каналы redis, на которые будет подписан tornado и через сокеты уже будет уведомлять клиентов. Но вот здесь только однонаправленная связь получается - это Django -> tornado. Но думаю мне должно этого хватить, но есть подозрения, что может многое поменяться и как бы себя уберечь от грядущих проблем, хотя бы чуть-чуть, может есть какие-то проверенные методы реализации данных вещей?
На данный момент бизнеса в Европе нет, но вдруг гражданин ЕС просто зарегается у нас, тогда мы попадаем под GDPR.