z0rgoyok: Да, 10 минут назад я сам уже нашел и уже сделал вывод controll'ов и на lock-screen и в info-center. У меня все это было написано, но не работало, так как не инициализировал AVAudioSession
Как смешно. А Вы сами эти ссылки читали? Или Вы думаете, что AVPlayer и AVAudioPlayer я сам из головы придумал? У меня и первая страница и вторая из результатов поиска уже все просмотрены. Я бы не писал сюда, если бы сначала не пытался сам сделать
Максим Тимофеев: и в POST параметрах я получу параметр с именем param и значением {a: 'b', c: 'd'}. Как я писал выше, я знаю, как получить один такой параметр. Мне же нужен массив, как в вопросе.
Максим Тимофеев: Не могли бы Вы привести полный пример, в котором есть 4 инпута, а в POST параметрах появляется один параметр со значением: [{key: 'a', value: 'b'}, {key: 'c', value: 'd'}] ?
значения a, b, c, d вводятся в инпуты
Александр А: да, признаю, не заметил param. Но это все равно не то, что нужно. Мне нужен массив param, в котором будет 2 объекта, каждый с ключом key и с ключом value. Пример есть в вопросе. Я понимаю, как получить {key: 'a', value: 'b'}. Я не могу получить массив из двух таких объектов
Александр А: и что это будет? Это будет отдельный POST параметр с именем из переменной $key. А мне надо, чтобы из четырех инпутов получился массив двух объектов, как в вопросе
Александр А: сейчас код показать не могу (с телефона), но там такие имена у инпутов: param[1][key], param[1][value]. Понятно, что при этом 1 передается, как ключ. А вот как передать без ключей? На форме должны быть пары для key/value
Спасибо. У нас сейчас так и работает, что nosql для аггрегации, а реляционка, как основное хранилище. Но, видимо, захотелось чего-то сильно изменить :)
Алексей POS_troi: Кеширование, конечно есть. Но для подсказок при поиске надо делать поиск по всем товарам. Можно, конечно, закешировать только пары name, id
Дмитрий Ковальский: Тогда это почти ничем не отличается от json полей в postgresql. Не знаю, почему, но это решение мне не нравится (хотя оно вполне жизнеспособно) :)
Мешает, например то, что речь о локализации не только одного поля, допустим, у продукта неограниченное кол-во полей, которые, опять же, может добавлять сам продавец и каждому этому полю нужна локализация. В таком варианте я не вижу приемлимого выхода с отдельной таблицей, вижу выход только с авто-сгенерированными токенами для этих полей и таблицей локализации для токенов. Сама структура продукта с неизвестным кол-вом полей, как мне кажется, лучше подходит для schemaless баз