есть сайт каталог. нужно паказывать цены на товар в зависимости от того какой юзер залогинен. и есть такой момент что товары могут обьединятся в группы по цене. тоесть например нужно показать товары от 150-300 рублей и эта цена - это динамическое поле которое вычисляется в зависимости от скидки юзера.

как такое провернуть красиво в джанге ?

Я бы хранил градации цен со скидками в каталоге. Если конечно у Вас скидка не динамическая, а как обычно до 4-5 градаций. (5%, 10%, 15%, 20%, 25%)
Пользователей группировал бы по скидкам.
Соответственно в views формировал бы запросы в зависимости от прав/скидки пользователя.
Ну а все остальное выдавать в шаблон для всех одинаково включая группировку 150-300.

Не знаю красиво это или нет. Почему-то “на лету” вычисление всех цен не кажется правильным.

Интересно, какие варианты являются красивыми.

а если скидка динамическая ?

Тогда:
Первый вариант: все цены на этапе формирования представлений в views. Но это чревато неоправданными нагрузками на мозг пользователей и на сервер. Естественно при условии наличия большого количества товаров и высокой посещаемости.

Второй вариант: обработку скидок отдать Javascript`у в шаблоне. Но на мой взгляд, при фильтрации гемморой еще тот.

И третий вариант смешанный: при выдаче каталога без фильтров отдать обработку скидок Javascript`у в шаблоне. При формировании фильтра учитывать скидку конкретного пользователя (условие увеличивать на скидку) в представлениях, выдавать в общих ценах и обрабатывать темже Javascript`ом. Это будет наименее нагруженный вариант как для сервера, так и для клиента.

да, спасибо. вообще если у заказчика появляются всякие нетрадиционные идеи, нужно с ним по этому поводу проводить разъяснительные работы ) нужно требования пересмотреть )

owlman
Второй вариант: обработку скидок отдать Javascript`у в шаблоне. Но на мой взгляд, при фильтрации гемморой еще тот.

Вот-вот, не стоит этого делать.

owlman
при выдаче каталога без фильтров отдать обработку скидок Javascript`у в шаблоне. При формировании фильтра учитывать скидку конкретного пользователя (условие увеличивать на скидку) в представлениях, выдавать в общих ценах и обрабатывать темже Javascript`ом. Это будет наименее нагруженный вариант как для сервера, так и для клиента.

Не вижу смысла тащить головняк из второго пункта.
Кроме того, любые действия Javascript нужно будет перепроверять на сервере.
Поэтому так делать нет смысла.

По поводу нагрузки.
Если использовать Javascript, то в выборку нужно включать больше данных - шире выборка.
Разве это снижение нагрузки (особенно на базу)?

unkier
Скриптовую клиентскую часть (значения фильтров с учетом скидок) тоже можно сделать в шаблоне.
Вычисляйте краевые значения и динамически формируйте файл скрипта или вставляйте скрипт инлайн в текст страницы.
Если со временем перейдете от динамической скидки на фиксированную и захотите кэшировать скрипты, то тут тоже проблем не возникнет. Нагенерируете с десяток скриптов с разными значениями скидки и краевых диапазонов и подключайте нужный.

Lexander
Не вижу смысла тащить головняк из второго пункта.
Кроме того, любые действия Javascript нужно будет перепроверять на сервере.
Поэтому так делать нет смысла.

А головняка из второго пункта и так не будет. Шаблону передаются суммы из каталога и процент скидки конкретного пользователя. Скрипт уменьшающий в шаблоне цены на заданное количество процентов не будет сложным. Зачем и самое главное, что проверять не совсем понимаю.

Lexander
По поводу нагрузки.
Если использовать Javascript, то в выборку нужно включать больше данных - шире выборка.
Разве это снижение нагрузки (особенно на базу)?

Эмм. Зачем включать больше данных? Для того чтобы скрипт вычел скидку? Все необходимые данные и так будут передаваться шаблону.
Javascript с базой никоем образом не работает. Он работает в шаблоне.
Речь ведь о Django шла, вот она родимая и работает с базой. В случае с фильтром она делает ту же выборку, что и обычно, просто условие фильтра корректируется с учетом скидки пользователя. Ну а на клиенте сумму уменьшит Javascript.
Даже если на одну страницу Вы будете выводить по 100 товаров одновременно, ни на базу, ни на клиента нагрузка не увеличится.

А Ваш комментарий с последующим ответом автору темы, удивил:

Lexander

owlman
Второй вариант: обработку скидок отдать Javascript`у в шаблоне. Но на мой взгляд, при фильтрации гемморой еще тот.

Вот-вот, не стоит этого делать.

И тут же:

Lexander
unkier
Скриптовую клиентскую часть (значения фильтров с учетом скидок) тоже можно сделать в шаблоне.
Вычисляйте краевые значения и динамически формируйте файл скрипта или вставляйте скрипт инлайн в текст страницы.
Если со временем перейдете от динамической скидки на фиксированную и захотите кэшировать скрипты, то тут тоже проблем не возникнет. Нагенерируете с десяток скриптов с разными значениями скидки и краевых диапазонов и подключайте нужный.

Противоречие? На чем собственно скриптовую клиентскую часть реализовывать Вы советуете, если Javascript использовать не стоит?

owlman
Шаблону передаются суммы из каталога и процент скидки конкретного пользователя. Скрипт уменьшающий в шаблоне цены на заданное количество процентов не будет сложным.

Не в сложности скрипта дело.

owlman
Зачем и самое главное, что проверять не совсем понимаю.

Все данные, сгенерированные на клиенте нужно проверять.
Формируя границы фильтра на стороне клиента вы предоставляете заведомо неизвестному посетителю возможность и инструмент для взлома.
Кроме того, если заложена скидка, то я ведь могу сделать так, чтобы она была вместо 5% 50%.
Или 10, чтобы не так заметно было.

owlman
Зачем включать больше данных?

owlman
Речь ведь о Django шла, вот она родимая и работает с базой.

А теперь копните еще глубже. База лежит на диске.
Заранее не известна ее фрагментация и сколько дисковых операций нужно СУБД для считывания всего массива данных. Плюс расходуемая память. И это только на одного пользователя.
А если их много и одновременно?
Поэтому ограничивать краевые условия нужно заранее - на сервере.

owlman
Противоречие? На чем собственно скриптовую клиентскую часть реализовывать Вы советуете, если Javascript использовать не стоит?

Никакого противоречия нет :)
Скриптовая часть - это и есть Javascript. Вот его то можно формировать динамически, используя стандартный механизм шаблонов Django.
Но вместо готовые рассчитанные значения подставлять в переменные фильтра.

А что касается головняка (“геморроя” в вашей терминологии ;)), то зачем же одну и ту же работу программисту делать и на сервере, и на клиенте. Особенно, если учесть, что использовать одну функцию не выйдет, т.к. для сервера и клиента они должны быть на разных языках.