Веб-Dev - Где сохранить состояние подобного корзине объекта?
Редактировать (после своего): ваш селектор должен работать.
Демо:
$(function () {
$('.btn-info').on('click', function () {
let attrId = $(this).prev().find('.selectpicker');
let attrId2 = attrId.attr("id");
alert(attrId2);
});
});<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<div>
<select name="APPLIEDSHIP" id="APPLIEDSHIP_ID" class="selectpicker bs-select-hidden"></select>
</div>
<button type="button" class="btn btn-info btn-xs">Print Id Of Selectpicker</button>12 ответов
Не зная платформу я не могу дать прямой ответ. Однако, так как Вы не заботитесь о заброшенных корзинах, затем я отличался бы от своих коллег здесь и предложил бы хранить его на клиенте. Почему хранилище это в базе данных, если Вы не заботитесь, отказываются ли от этого?
С другой стороны, это действительно зависит от размера объекта, который Вы храните - cookie имеют свои пределы, в конце концов.
Редактирование: Ahh, asp.net MVC? Почему бы не использовать систему профиля? Можно включить анонимный профиль, если Вы не хотите потрудиться заставлять их войти в систему
Я сказал бы, хранят состояние где-нибудь на сервере и коррелируют его к сессии пользователя. В то время как cookie мог якобы быть равным местом для хранения вещей, если Вы рассматриваете безопасность, и размер данных, сохраняя как можно больше данных по серверу становится хорошей вещью.
, Например, в общедоступной терминальной установке, для кого-то было бы нормально смотреть на содержание cookie и видеть список? Если так, штраф cookie; в противном случае Вы просто захотите идентификатор, который связывает пользователя с данными. Выполнение, которое также позволило бы Вам гарантировать пользователю, аутентифицируется в сайте для получения до тех данных вместо того, чтобы хранить все на машине - им была бы нужна некоторая форма учетных данных , а также идентификатор сессии.
С точки зрения размера, уверенной, Вы не собираетесь быть слишком соответствующими о 4K cookie или чем-то для пользователя браузера/широкополосной связи, но если одна из Ваших целей должна позволить мобильному телефону или BlackBerry (не на 3G) соединять и иметь мгновенный опыт (и не тарифицированы за данные), минимизирование объема данных, передаваемого клиенту, будет ключевым.
серверное хранилище также дает Вам некоторую гибкость, упомянутую в некоторых из других ответов - пользователь может сохранить их корзину на одной машине и продолжить работать с нею на другом; можно связать корзину с некоторой формой учетных данных (а не переходная сессия) и сохранить корзину еще долго после того, как пользователь очистил их cookie; Вы немного больше попадаете путем отказоустойчивости - если браузер пользователя отказывает, сайт все еще имеет живые и здоровые данные.
, Если отказоустойчивость важна, Вам будет нужно своего рода персистентное хранилище как база данных. В противном случае в приложении память прекрасна, вероятно, но Вы потеряете данные, если приложение перезапустит. Если Вы находитесь в среде фермы, хранилище должно быть централизованно доступным, таким образом, Вы снова смотрите на базу данных.
, Принимаете ли Вы решение ввести переходной сессией или учетными данными, собирается зависеть от того, могут ли пользователи сохранить свои данные и возвратиться позже для получения их. Переходная сессия будет в конечном счете очищена, как "отказались", и возможно это в порядке. Связь с профилем пользователя позволит пользователю сохранить их данные и явно отказаться от них. Так или иначе я использовал бы своего рода запоминающее устройство как база данных для отказоустойчивости и центральной доступности. (Или возможно я - сверхразработка решение?)
Если Вы будете заботиться о поддержке пользователей без включенного JavaScript, то серверные сессии позволят Вам использовать перезапись URL.
Если бы относительно короткий тайм-аут (приблизительно 2 часа, в зависимости от Вашей конфигурации сервера) хорошо для корзины, то я сказал бы сессию серверной стороны. Это быстрее и более эффективно, чем доступ к DB.
при необходимости в более долгой персистентности (говорят, что некоторым пользователям нравится уезжать и возвращаться на следующий день), затем сохраните его в cookie, который очевиден для трамбовки (используйте шифрование или хеши).
Это был мой опыт с Коммерческим Стартовым набором и Витриной MVC (и другие сайты, которые я создал), что независимо от того, что Вы думаете теперь, информация о взаимодействии с пользователем с Вашими "продуктами" является главной для бизнес-парней. Существует столько метрик для получения - это гаек.
я сохраню Вас весь материал, я был через - что безусловно было самым успешным для меня, просто создает объект Порядка с состоянием "NotCheckedOut" и затем добавляет объекты к нему, и пользователь добавляет объекты. Это позволяет пользователям иметь больше чем одну корзину и позволяет Вам взрывать tar из таблицы Orders. Также довольно легко провести порядок - просто изменяют состояние.
Сохранение, "когда они идут" также, позволяет пользователю возвращаться и разрушать корзину, если они не могут по некоторым причинам. Прощение является серьезным с электронной коммерцией.
Cookie сосут, сессия сосет, Профиль присоединен к понятию пользователя, и это поражает DB, таким образом, Вы могли бы также использовать DB.
Вы могли бы думать , Вы не хотите делать это - но Вы нуждаетесь к доверие меня и знаете, что необходимо будет действительно подать зубрил статистики некоторые данные позже. Я обещаю Вам.
Я рассмотрел то, что Вы предлагаете, но не имели клиентского проекта все же для попытки его. Самым близким на самом деле является список покупок, который можно найти здесь...
http://www.scottcommonsense.com/toolbox.aspx
Нажимает на Grocery Checklist для открытия окна. Это действительно использует ASPX, но только управлять ссылками JS, помещенными на странице. Остальное сделано через Ajax с помощью веб-сервисов.
Ранее я создал ASP.NET 2,0 сайта для торгового сайта, который использовал скоро/автор cookie автоматически. Каждый предоставляет Вам значение GUID, которое можно использовать для идентификации пользователя, который затем связан с данными в базе данных. Я хотел подлинные cookie, таким образом, пользователь мог переместиться в различные компьютеры; работа, домой, и т.д. Я избегал использования полей Profile для содержания на сложный объект ShoppingBasket, который был популярен в течение времени во всем ASP.NET 2,0 книги. Я не хотел иметь дело с "волшебными" проблемами сериализации как структура данных, изменяемая со временем. Я предпочитаю справляться, изменения схемы дб с обновляют/изменяют сценарии, синхронизировавшие с изменениями программного обеспечения.
Со скоро/автор cookie, идентифицирующими пользователя на клиенте, можно использовать Ajax ASP.NET, клиентский для вызова веб-сервисов аутентификации с помощью прокси JS, которые предоставляются Вам как часть ASP.NET. Необходимо реализовать Членство API, чтобы, по крайней мере, аутентифицировать пользователя. Остальная часть реализации поставщика может бросить NotImplementedException безопасно. Можно затем использовать собственные веб-сервисы ASMX через Ajax (см. атрибут ScriptReference), и обновите страницы с данными серверной стороны. Можно полностью покончить со страницами ASPX и просто использовать статический HTML/CSS/JS, если Вам нравится.
один большой протест является утечками памяти в JS. При пребывании на той же странице долгое время увеличивает потенциальную проблему с утечками памяти. Это - риск, который можно минимизировать путем тестирования на долгие сессии и использования инструментов как Firebug и другие для поиска утечек памяти. Используйте инструмент JS Lint, а также он поможет определить основные проблемы, когда Вы идете.
Я был бы склонен сохранить его как объект сессии. Это вызвано тем, что Вы не обеспокоены заброшенными корзинами и можете поэтому удалить издержки хранения его в базе данных, поскольку это не необходимо (не говоря уже о том, что Вам также была бы нужна некоторая стандартная программа очистки для удаления корзин, от которых отказываются, из базы данных).
Однако, если Вы хотели бы, чтобы пользователи смогли сохранить свои корзины, затем параметр базы данных лучше. Таким образом, пользователю, который зарегистрирован, сохранят их корзину через сессии (поэтому, когда они возвратятся к сайту и входу в систему, их корзина будет восстановлена).
Вы могли также использовать комбинацию двух. Пользователи, которые приезжают в сайт, используют основанную на сессии корзину по умолчанию. Когда они входят в систему, все объекты перемещены от основанной на сессии корзины до основанной на базе данных корзины, и любое последующее действие корзины применяется непосредственно к базе данных.
В DB, связанном с тем, что Вы используете для сессий (сессии дб/кэш-памяти, подписанные cookie) или аутентифицируемому пользователю.
Вы предполагаете людей, бывших должных смочь запуститься на одной машине (например, их работа ПК), но continue/finsih от другой машины (например, домашний ПК)? Если так, ответ очевиден.
Если Вы не заботитесь о заброшенных корзинах и имеете в распоряжении вещи для кого-то смешивающего с данными по стороне клиента... Я думаю, что cookie был бы хорош - особенно, если это - просто cookie данных JSON.
Я использовал бы (зашифрованный) cookie на клиенте, который держит идентификатор пользовательской корзины. Если это не действительно оживленный сайт, затем отказался от корзин, не заполнит базу данных также очень, и можно выполнить регулярную задачу администрирования для очистки заброшенных заказов вниз, если Вы заботитесь так очень. Также делая его этот способ, которым пользователь сохранит их порядок, если они закроют свой браузер и уйдут, корзина на сессии была бы очищена в этой точке..
Наконец это означает, что Вы не должны волноваться о написании кода для контакта с de/serialising данных из клиентского cookie при позже волнении о фактическом помещении тех данных в базу данных, когда это преобразовывается в порядок (слишком много точек отказа на мой вкус)..