Округление цен до 10 рублей в Smarty

[Flash]

Округление цен до 10 рублей в Smarty

Подскажите как в шаблоне Smarty округлить, например цену 456,56 до 460.

 

[dimagolov]

Flash, тебе не кажется, что округление это не задача для шаблона?

 

[Flash]

А почему нет? До целых округляет, отлично с этим шаблон справляется, плюс в шаблон передается один массив, а потом очень много разных данных получаем (к примеру разные столбцы цен).

 

[baev]

У смарти очень подробная документация, в том числе — на русском.
Найти там то, что Вам нужно, — дело пары минут.

 

[Flash]

http://www.smarty.net/manual/ru/language.modifier.string.format.php
http://php.net/sprintf
ну что-то в мануале нет такого, я сперва его посмотрел потом писать стал, в принципе выйти из положения можно разделив на десять округлив до целых и умножить снова на десять только наверняка есть более грамотный подход...

 

[Вурдалак]

Re: Округление цен до 10 рублей в Smarty

{$price|round:-1}

 

[Flash]

Вурдалак
Спасибо мил человек!!!

 

[Adelf]

Flash, тебе не кажется, что округление это не задача для шаблона?

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

 

[С.]

То есть можно округлять, а можно не. На вкус верстальшика?

 

[Adelf]

С.
Я бы сказал дизайнера. А потом уже верстальщик сделает, как дизайнер попросил. А проггер не при делах и это правильно.

 

[С.]

То есть можно округлять, а можно не. На вкус дизайнера?

 

[c0dex]

С.
Вкус дизайнера, думаю, тут не при чем. В шаблоне это решить более гибко, нежели зашить в php код, куда верстала/дизайнер доступа не имеют. И потом поменять что-то в выводе будет более геморройно имхо.

 

[dimagolov]

c0dex, по-моему округление или нет цен это бизнес-логика. Ну округлит дизайнер цены до 10 рублей, а кто будет покрывать недостачу при округлении вниз и кому будет идти прибыль от округления вверх? И кто будет отвечать перед налоговой и защитой прав потребителя за публикацию одних цен, а торговлю по другим? Тоже дизайнер? Что-то сомневаюсь.

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

 

[Adelf]

dimagolov
Ой не надо до крайности доводить
Ценник - публичная оферта, т.е. как договор. Там никто не будет округлять.
Иногда по каким-либо причинам дизайнер может захотеть дать в данном месте приближенные значения. Зачем дергать проггера по этому поводу? Это логика представления. Проггер отдает в шаблон значение в исходном виде. А верстальщик может показать его так, как считает нужным дизайнер.

 

[c0dex]

dimagolov
Блин, вот опять. Я не говорил о какой-либо налоговой и обмане пользователей. Не перевирай мои слова.
Я сказал именно о том, что так сделать с моей точки зрения построения приложения правильно.
Я считаю, что такие операции должны быть санкционированы заказчиком, то есть округлять или нет цену с 59,456 до 59,46 рублей или до 59,45. И никто никого обманывать не должен.

Хотя, по большому счету, где и как цены округлять - это дело каждого индивидуального разработчика.

 

[dimagolov]

Adelf, я могу представить только одну ситуацию с ценами, когда такое округление допустимо. Это слоган "рубашки от 190 руб!!" где 190 берется из select min(price) from goods where type = 123. тут спорный вопрос, где именно нужно округлять, но так как запрос будет писать прогер, то почему он же не может сделать округление согласно ТЗ?

посмотрим на ситуацию с другой стороны. вся работа с ценами/суммами и прочим это бизнес-логика и отвечает за нее тот, кто ее пишет. как не попасть в ситуацию, когда бизнес-логика правильна, а отображается по-левому, вернее не так, как ее разработчик ожидают? и все потому, что мы потянули округление чего-то в шаблон. еще веселее будет, если шаблон с округлением написан год назад, но всегда давали данные с той же точностью, до которой прописано округление, а тут требования изменились и в бизнес-логике точность изменили, и тут округления в шаблоне заработали. причем заметить это будет возможно далеко не сразу, если % округленных данных окажется невелик.

в общем, зачем наживать себе проблемы добавляя в шаблон лишнее?

 

[Adelf]

dimagolov
а чего ты к ценам привязался
Допустим в магазине 1050 товаров. Имеет право верстальщик написать "больше чем 1000"?
Или mp3-файл длительностью 4 минуты 21 секунды. Проггер ессно отдает точный результат, а верстальщик может писать "~4 минуты". Много еще случаев можно придумать.
Цены - согласен. Слишком важная вещь, чтобы округлять. И редко когда это делают. Но если ТСу это понадобилось... то совсем необязательно делать это както по-другому, если в других случаях это делают в представлении.

 

[С.]

А когда в магазине будет 1900 товаров, то "интеллектуальная" логика отображения напишет "почти 2000!" Слоганы прогаммно писать? Не надо натягивать, нет практического и логически оправданного округления в шаблонах.

-~{}~ 19.01.10 19:11:

Кстати Смарти еще не умеет округлять минуты/часы/сутки?

 

[Flash]

Ребята что-то вас так плёвый вопрос раззадорил? Мне удобнее в шаблоне округлять, так как столько всяких условий накладывается, что нет смысла это в пхп пихать (тогда очень много данных в шаблон передавать придется). Округление до десяток была просьба продавца т.к. имхо розница и продавец в праве устанавливать цены которые хочет.

 

[С.]

Да ты в своем проекте можешь воротить, как захочешь, хоть в базу лазить в шаблоне. Мы говорим об идеологии и что идеологически верно, а что нет.

Народ во имя Великой Семантики может такое нагородить, но таблицы в верстку ни за что не допустит. А мы вот MVC молимся. И ты, язычник поганый, сгинь!