у тебя есть одна entity, по сути это просто PK в таблице. далее уже по типу этой сущности к ней подтягиваются аттрибуты

ну тяни юзера да обновляй

из дефалтсов

обратно пиши

ок, лучше пример попонятнее

холодильник, телевизор, вибратор

сущность одна - product

но набор параметров - разный

ну храни массивом с разным типом

ну йома так и делаю

Понятно, ребята, тут пхп-дривен-девелопмент ?

EAV это не php-related штука

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

Всем Привет Ищу заинтересованных людей Нужны : Веб дизайнер Бек энд разработчик Это стартап Территориально СПб По всем вопросам в лс

У когото есть скриптик для добавления одинаковых файлов для разных таргетов из папки с ресурсами в хсассетс?

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

учи питон

Всем Привет Ищу заинтересованных людей Нужны : Веб дизайнер Бек энд разработчик Это стартап Территориально СПб По всем вопросам в лс

Вакансии сюда: https://t.me/mobile_jobs

учи питон

Я уже научил своего питона всему, что требуется

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

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

Да то другие типы

Типы данных пхп тут ни причем

Типы полей

Я понимаю. Но секс с типами в одной переменной от этого меньше не становится..

Text, textarea, choice, dictionary, town

это типы?

Типы полей формы, да

Это вьюшки или типы данных

То есть уже тут хрень какая-то выходит ?

ну да

Как хрень?

Стандарта нету что ли

ты типа на каждом шагу постишь юзера

с разными полями

Ну таков eav

может выкинуть его

Пример про product более понятен

и сделать нормально

Ты не сделаешь нормально

что тебе мешает собрать целиком модель, а не постить на каждом шагу

если боишься что потеряется храни локально

Я не постю на каждом шагу

Вот даже гугл какбы намекает

Пользователь жмет на кнопку "добавить товар", выбирает тип товара

Напрмер, холодильник

В мобайле - упущено

Иван ты капец

Какое отношение структура бд имеет к мобайлу?

ты про товары, а мы тебе про юзера

юзер добавляет других юзеров или себя?

Давай про товары, про юзера плохой пример

Кейс у тебя какой?

Пользователь жмет на кнопку "добавить товар", выбирает тип товара

Выбрал "холодильник". Подтянулись поля для холодильника, форма отстроилась

зачем ты тянешь решение кейса с товарами на юзера, если он один и тип у него один?

Вакансии сюда: https://t.me/mobile_jobs

Посмотрел кстати, там только ведроиды в основном

тебе так критично тянуть только те поля что будут на вьюхе?

зачем ты тянешь решение кейса с товарами на юзера, если он один и тип у него один?

Я пример про юзера стремный привел

один раз вытянуть юзера целиком и передавать по экранам

Дослушай

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

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

У меня нет костылей с хранением. В мобайле он много где используется

Мобайл тут вообще ни при чем

В вебе я храню то же самое в localStorage браузера и там все прекрасно сериализуется и десериализуется

ну добавь к сущности товара сущность с данными которые надо хранить например

ERROR: S client not available

в бд

раз там у каждого могут быть разные

но это какой то веб

А в чем вопрос, собственно? Как сохранить словарик ключ-значение?

вообще да

но срач про пхп интереснее

Нет, как в userdefaults положить объект и его потом достать

Без дополнительных костылей

Нет, как в userdefaults положить объект и его потом достать

NSCoding, если в userDefaults. Правда, мне кажется, что дефолтсы не совсем для этого

Особенно, если форм тысяча

Вот юзер выбрал город "москва", это struct, у которого есть id и name. Мне эту фигню надо в дефолтс сохранить

в плист хз

Да данных немного

почему бы просто id не хранить

отображать еще надо

а по id уже потом выдергивать name

Потому что тогда тоже нужен дополнительный код для того, чтобы по id получить name

А я изначально от этого и хотел уйти

id уникальный, а name нет

поменяешь name, у кого то останется старый

мне кажется выстрел себе в ногу

а по id уже потом выдергивать name

по моему норм вариант

По условию задачи не подходит

Ну хз

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

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

А вот нихера

Учи ООП.

Учи eav

А не две нормальные формы бд

https://github.com/kelseyhightower/nocode

Учи eav

Поржал. К EAV задача вообще отношения не имеет

Я с твоего "учи ооп" примерно так же поржал