Цитата:
select * from tablename where brand='Конь тыгыдымский' Получил листинг. Там еще могут быть опции сокращения выборки. Понажимал, получил. Теперь хочешь запомнить какую-то запись из списка. Где ее запомнить? Где угодно, главное, чтобы была привязка к юзеру. Автоматическую привязку обеспечивают куки, поскольку они доступны и на сервере. Без куков можно обойтись только принудив юзера регистрироваться, поскольку тебе нужен его ID, привязка к его сущности. Юзер тычет "сохранить" скрипт запоминает в куках или в бд. Юзер тычет "оформить" или там "корзина", скрипт достает список запомненного и выводит. select * from tablename where product_id in(join(',',$saved_id_list)); Все нах. |
Данные из БД - рид-онли. А все юзерские списки - едитабле. Виш-лист, избранное, лайки, корзина - это юзерские списки. Виш-лист это просто идешники, лайки это пара идешник - оценка, корзина это пара идешник - количество. Что ты еще можешь изобрести сверх этих архаичных сущностей? Капец блин, захерачат сами себе могучий Маня-мир и мудохаются в нем с уродской аксиоматикой. Ты и попал сюда из Маня-мира. Если бы ты изучал реальный мир, тебя бы сдесь не было. Давно бы уже написал все, ну максиумм бы пришел пожаловаться почему == сравнивает блеать без типа.
|
Цитата:
Не берите на веру, что фореймворки есть де-юре Закон, а следовательно в них все безупречно. Сперва рассмотрим вот это: var id_regex = new RegExp('(' + prefix + '-\\d+-)'); var replacement = prefix + '-' + ndx + '-'; Уже плохо, так как используется разбор рег. выражением, что уже накладно. А ведь если и требуется нумерация, можно ведь поступать так же как в жизни - ул. Академическая 1, ул. Академическая 2, ... Знакомо? Да и от программирования весьма далеко, но ведь просто. Если это взять на вооружение, то в первичный список в атрибут data-num помещать номер, а связанный с ним список получает ID как например s1, s2, s3, ... Для обращения к связанному списку получаем номер из атрибута и соединяем его с "s" и получаем ID элемента к которому нужно обратиться. Но что самое ужасное, так это именование полей так же дремуче как и ID элементов. Что придется делать на сервере - сервер получает вот такой набор ключей form-1-buy_tabako_brand, form-2-buy_tabako_brand, form-3-buy_tabako_brand и т.д. Для простоты опустим факт того, что серверный сценарий должен проверять наличие ожидаемых им ключей, и пусть "берем на веру, что все гут", а данные присланные для одного адресата. Тут можно не интересоваться именами ключей, а получить их значения и далее по условию. Но если даже веровать, то ситуация резко усугубится, если данные будут присланы для двух адресатов, и второй набор будет таким form-1-buy_bibika_brand, form-2-buy_bibika_brand, form-3-buy_bibika_brand и т.д. Просто взять значения каждого из наборов и далее оперировать ими уже не получится. Серверный сценарий вынужден будет производить разбор каждого ключа, что просто сводит на нет все удобства работы с массивом. Ладно если ключей раз, два и все, а если представить, что таким же образом именовать поля формы где либо в административном разделе, с большим числом записей предполагающих пакетное обновление? Это будет кошмар. |
Часовой пояс GMT +3, время: 23:52. |