Комментарии 138
Начало плохое, а сама инфа интересная :) пойду заказывать тазики :)
Я долго думал как может интернет-магазин работать в офлайне... И только потом дошло :))))
А статья интересная, спасибо.
А статья интересная, спасибо.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
т.е. косяк был? :)
Вот пример плохого кода. Я бы запомнил предыдущее значение в сессию. Если пользователь ввел бы неверное, то выдал бы ему сообщение, а не тупо поставил бы единицу. И вернул бы его прошлое значение.
не пишите так никогда, как тут, делайте юзабильнее сервисы...
предыдущий код автора комментария вообще не верен.
PS. Пользуйтесь знаком || для логического или. Оно является стандартом для php и повышает качество кода.
не пишите так никогда, как тут, делайте юзабильнее сервисы...
предыдущий код автора комментария вообще не верен.
PS. Пользуйтесь знаком || для логического или. Оно является стандартом для php и повышает качество кода.
Можно ссылку на стандарт?
Имхо, лучше писать or - более читабельно.
Имхо, лучше писать or - более читабельно.
Прежде чем выкладывать какой-то код много раз подумайте.
Or писать более читабельно - это бред. OR, AND и остальные числовые операторы сравнения в PHP используются только тогда, когда следует сначала проверить логические условия, а потом, уже выполнить выражения в условиях.
Я не говорил, что есть какой-то четкий стандарт, но принято писать ||, так как в языках программирования сначала выполнаются выражения в условии, а потом уже вычисляется логическое значение самого условия.
Опытный программист, увидев "OR", будет невзначая искать почему вы его применили, где у Вас в условии выражения, вычисления которых нужно оставить на потом...
Надеюсь убедил...
Or писать более читабельно - это бред. OR, AND и остальные числовые операторы сравнения в PHP используются только тогда, когда следует сначала проверить логические условия, а потом, уже выполнить выражения в условиях.
Я не говорил, что есть какой-то четкий стандарт, но принято писать ||, так как в языках программирования сначала выполнаются выражения в условии, а потом уже вычисляется логическое значение самого условия.
Опытный программист, увидев "OR", будет невзначая искать почему вы его применили, где у Вас в условии выражения, вычисления которых нужно оставить на потом...
Надеюсь убедил...
ниччё не понял, как можно сначала проверить, а потом вычислить то, что надо проверять?
НЛО прилетело и опубликовало эту надпись здесь
Понимаете, автор не совсем верно сказал пременив слово стандарт. Правильно будет сказать "де-факто". То есть процент близкий к 100% программ на ПХП используют || для логического оператора ИЛИ, а не or. То есть предположим, что вы по какой-то причине перестали поддерживать проект и его поддерживает другой человек (не такой умный как вы). И в этом случае or его может поставить в тупик. Я конечно понимаю, что вам может быть без разницы, что там в дальнейшем будет с вашей программой, но вот как-то так.
Использование || вместо or это как правила хорошего тона. Ну то есть как писать if (), а не if(), ну и много других правил хорошего кода. Их можно конечно же не придерживаться, а писать так как ты пишешь, но тогда в больших проектах остальные программисты могут часто на тебя ругаться, что есть не очень хорошо.
Использование || вместо or это как правила хорошего тона. Ну то есть как писать if (), а не if(), ну и много других правил хорошего кода. Их можно конечно же не придерживаться, а писать так как ты пишешь, но тогда в больших проектах остальные программисты могут часто на тебя ругаться, что есть не очень хорошо.
НЛО прилетело и опубликовало эту надпись здесь
Все бы вам помериться чем-нить. В детстве не намерились? Ну если нет - покажите пример. С удовольствием гляну на проекты, которые реализованы без соблюдений правил хорошего тона. Я не хочу сказать, что ваш код не правильный или что-то еще. Просто есть правила хорошего тона (открывать перед дамой дверь или что-то в этом духе) и есть просто законы физики (ускорение с которым двигается тело, прямопропорционально силе на него действующей и обратно пропорционально массе). Ваш код абсолютно правелен с точки зрения закона, но не красив с точки зрения правил хорошего тона оформления.
Даже в вашем примере есть соблюдение правил хорошего тона. Скажем то что вы открывающуюся фигурную скобку поставили на следующую строку от оператора if (во всех примерах на сайте php.net да и в PEAR модулях) открывающаяся фигурная скобка ставится на ту же строку, что и оператор. Но вам (и мне тоже) удобнее её (фигурную скобку) ставить на новую строку. Так же и мне и еще 90% программистов удобнее использоваться ||. Но вас никто не заставляет использоваться || вместо or. Вам просто рассказали правила хорошего кодирования.
Даже в вашем примере есть соблюдение правил хорошего тона. Скажем то что вы открывающуюся фигурную скобку поставили на следующую строку от оператора if (во всех примерах на сайте php.net да и в PEAR модулях) открывающаяся фигурная скобка ставится на ту же строку, что и оператор. Но вам (и мне тоже) удобнее её (фигурную скобку) ставить на новую строку. Так же и мне и еще 90% программистов удобнее использоваться ||. Но вас никто не заставляет использоваться || вместо or. Вам просто рассказали правила хорошего кодирования.
НЛО прилетело и опубликовало эту надпись здесь
Я вас ни в чем не упрекал, я только попытался донести до вас, что хотел сказать вам автор. Мне бы было "померяться" с вами лет 5 назад, а так - http://www.habrahabr.ru/blog/webdev/1646…. У вас лично в этом топике я не увидел ничего подобного.
Не смысла язвить по поводу всего одного комментария. Я Вам прекрасно объяснил почему нужно писать так как я сказал. Дело даже не в негласных стандартах, а в специфике PHP.
И еще... никогда не говорите: "я пишу проект один и буду оформлять код как мне нравится, все равно его никто не увидит". Я бы у такого человека ничего бы никогда не заказал бы.
И еще... никогда не говорите: "я пишу проект один и буду оформлять код как мне нравится, все равно его никто не увидит". Я бы у такого человека ничего бы никогда не заказал бы.
Код должен быть одновременно правильным, красивым и эффективным. Причем порядок этих параметров именно такой. Нельзя уродовать код в угоду производительности. Финтов ушами либо не должно быть, либо должно быть много.
Я разве что-то сказал в сторону уродования кода в угоду производительности? Вы прочитали мой комментарий?
Но в любом случае я с вами немного несоглашусь: сначала правильный, потом эффективный, а потом уже красивый.
И, кстати, чем OR красивее ||?
Но в любом случае я с вами немного несоглашусь: сначала правильный, потом эффективный, а потом уже красивый.
И, кстати, чем OR красивее ||?
1. Вы негативно отнеслись к моему комментарию :). Высказывание про уродование было привязано к моему контексту => кажется, вы не воспринимаете контекст :)
2. Красивый код может быть эффективным, эффективный не обязательно может быть красивым :) Я скорее выберу красивый, даже если он проигрывает эффективному в производительности в 10 раз, но это мое мнение. Кстати, я программирую на Perl, и этот язык так устроен, что чем красивее напишешь код, тем с большей вероятностью он будет эффективнее, но так конечно не всегда :)
3. Я не говорил, что or красивее ||. По крайней мере в этой ветке. В большинстве случаев между этими операторами (в PHP) нет разницы. И какой из них использовать полностью Ваш выбор, главное чтобы Вы понимали их особенности и отдавали себе отчет в том, что делаете. Но с точки зрения читаемости кода or конечно читаемее. Лично я предпочитаю ||, а or использую в исключительных случаях и только тогда, когда по другому никак :)
2. Красивый код может быть эффективным, эффективный не обязательно может быть красивым :) Я скорее выберу красивый, даже если он проигрывает эффективному в производительности в 10 раз, но это мое мнение. Кстати, я программирую на Perl, и этот язык так устроен, что чем красивее напишешь код, тем с большей вероятностью он будет эффективнее, но так конечно не всегда :)
3. Я не говорил, что or красивее ||. По крайней мере в этой ветке. В большинстве случаев между этими операторами (в PHP) нет разницы. И какой из них использовать полностью Ваш выбор, главное чтобы Вы понимали их особенности и отдавали себе отчет в том, что делаете. Но с точки зрения читаемости кода or конечно читаемее. Лично я предпочитаю ||, а or использую в исключительных случаях и только тогда, когда по другому никак :)
Ребята (и девчата), по-моему кто-то кого-то лечит. Так многа букаф во всей ветке и так мало смысла шописец.
А тут уже философия просто пошла :)
У каждого она своя, но со стороны кажется, что кто-то кого-то лечит. Хотя на самом деле просто обмениваемся мнениями.
Пофлудим и успокоимся. Никто не пострадает, а даже наоборот, опыта какого-никакого да наберемся :)
За нас можно не беспокоиться, не пересремся :) А читать наш бред Вас никто не заставлял ;)
У каждого она своя, но со стороны кажется, что кто-то кого-то лечит. Хотя на самом деле просто обмениваемся мнениями.
Пофлудим и успокоимся. Никто не пострадает, а даже наоборот, опыта какого-никакого да наберемся :)
За нас можно не беспокоиться, не пересремся :) А читать наш бред Вас никто не заставлял ;)
НЛО прилетело и опубликовало эту надпись здесь
Вот чего стоят все эти ваши комментарии?
Операторы || и or не то что имеют разные приоритеты. Они в некоторых языках работают по разному.
Возьмем самые простые примеры:
PHP (ваш любимый).
print 0 || 5; выведет 1. Выражение 0 || 5 вернет 1.
print 0 or 5; выведет 0.
Еще 2 строчки
if (print 0 or print 1) print 2345
if (print 0 || print 1) print 2345
Что выведут, сами догадайтесь.
Теперь Perl (мой любимый ;) )
print 0 || 5; выведет 5.
print 4 or 5; Warning. правильно писать print 4 or print 5;
Те самые 2 строчки в данном случае сработают так же
if (print 0 or print 1) print 2345
if (print 0 || print 1) print 2345
В PHP с || и or (&& и and) стоит играться только в случае использования оператора присваивания, в остальных случаях операторы равнозначны, с or код немного читаемее, вот только в PHP это значения особого не имеет, язык никакой с эстетической точки зрения. В Perl эти функции можно использовать гораздо изящнее, они там точно не математические и не совсем логические :)
P.S. и давайте не меряться письками в области реализованных проектов, особенно популярных. Популярные проекты одним человеком не делаются.
Операторы || и or не то что имеют разные приоритеты. Они в некоторых языках работают по разному.
Возьмем самые простые примеры:
PHP (ваш любимый).
print 0 || 5; выведет 1. Выражение 0 || 5 вернет 1.
print 0 or 5; выведет 0.
Еще 2 строчки
if (print 0 or print 1) print 2345
if (print 0 || print 1) print 2345
Что выведут, сами догадайтесь.
Теперь Perl (мой любимый ;) )
print 0 || 5; выведет 5.
print 4 or 5; Warning. правильно писать print 4 or print 5;
Те самые 2 строчки в данном случае сработают так же
if (print 0 or print 1) print 2345
if (print 0 || print 1) print 2345
В PHP с || и or (&& и and) стоит играться только в случае использования оператора присваивания, в остальных случаях операторы равнозначны, с or код немного читаемее, вот только в PHP это значения особого не имеет, язык никакой с эстетической точки зрения. В Perl эти функции можно использовать гораздо изящнее, они там точно не математические и не совсем логические :)
P.S. и давайте не меряться письками в области реализованных проектов, особенно популярных. Популярные проекты одним человеком не делаются.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вы основателей и программистов не путаете? Если уж на то пошло, то у ютуб было 3 основателя, один потом бросил все и учиться пошёл.
НЛО прилетело и опубликовало эту надпись здесь
Спор уходит в другое русло. Лично мой взгляд вы путаете основателей и разработчиков, да они вначале были разработчиками. Но потом (ну разве что кроме Торвальдса) они отошли от программирования. Да и вообще - пишите как хотите, я всего лишь хотел сказать, что 90% программистов употребляют || вместо or (когда нету разницы).
НЛО прилетело и опубликовало эту надпись здесь
Мои знакомые 10 программистов, к мнению которых я прислушиваюсь используют ||. Еще несколько знакомых программситов (как начинающих, так и опытных) тоже используют ||. Ни один из опрошенных мной моих знакомых программистов не использует or. Вот такая вот статистика. ну то есть выборка не так что бы репрезентативна, но по ней так вообще 100% (порядка 30 програмеров), и я просто сделал скидку 10%.
P.S. Скотт где вы так хорошо выучили русский?
P.S. Скотт где вы так хорошо выучили русский?
НЛО прилетело и опубликовало эту надпись здесь
Не нахожу. Ибо это только из опрошенных 30 человек. То есть из 31 человека 30 и получается, что около 3% пользуют or.
Про and я вообще ничего говорить не буду ибо мне уже пофигу. Еще раз могу сказать что я использую &&, а не and (когда нету разницы!!!).
Ну... А мне правда интересно, что студент школы актерского мастерства делает в программировании. Так сказать "Что делает служитель мельпомены в наших рабочих кругах". И это не ирония или наезд. Правда интересно.
Про and я вообще ничего говорить не буду ибо мне уже пофигу. Еще раз могу сказать что я использую &&, а не and (когда нету разницы!!!).
Ну... А мне правда интересно, что студент школы актерского мастерства делает в программировании. Так сказать "Что делает служитель мельпомены в наших рабочих кругах". И это не ирония или наезд. Правда интересно.
Это вы называете померяться? Т.е. намек на то, что в любом из перечисленных проектов Вы - один из программистов? Вселенский Вам зачот и поклон в таком случае. Вы великий человек!!!
НЛО прилетело и опубликовало эту надпись здесь
А есть смысл меряться с Вами? В чем этот смысл? Загинать пальцы, это не мой стиль.
Я в популярных проектах особо не участвовал (ну если только madeinrussia.tv. Разработан двумя программистами, в том числе мной. Мой вклад: постинг видео на видеохостинги и обзоров в блоги). От создания сайтов я отошел, нашел более интересные области.
Показать рабочие проекты я не могу в силу многих веских причин. Я разрабатываю высоконагруженные вэбсервисы и пишу софт для BlackSEO. Также пишу высоконагруженных пауков (20Мбит/сек), пример кода, естественно упрощенный. Если Вам интересно померяться пузом по качеству кода либо по производительности, то этим я буду заниматься не здесь.
Я в популярных проектах особо не участвовал (ну если только madeinrussia.tv. Разработан двумя программистами, в том числе мной. Мой вклад: постинг видео на видеохостинги и обзоров в блоги). От создания сайтов я отошел, нашел более интересные области.
Показать рабочие проекты я не могу в силу многих веских причин. Я разрабатываю высоконагруженные вэбсервисы и пишу софт для BlackSEO. Также пишу высоконагруженных пауков (20Мбит/сек), пример кода, естественно упрощенный. Если Вам интересно померяться пузом по качеству кода либо по производительности, то этим я буду заниматься не здесь.
НЛО прилетело и опубликовало эту надпись здесь
:)
Не нужно писать что бы я бы сделал. Я всего лишь обратил внимание автору на его кусок кода. Вы же как скандалист начали развивать скандал. Я старше вас, я по профессии программист и пишу программы со школы. Из этого вывод я могу сделать, что я более опытен в этих делах. так что имейте уважение к моему мнению и не насилуйте мозги остальным своим трепом.
НЛО прилетело и опубликовало эту надпись здесь
это как же надо спешить с кодингом, чтобы не предусмотреть полноценную проверку входных данных.
хуже может быть лишь прямая вставка из запроса в SQL-выражение.
друзья, давайте просто-напросто ДУМАТЬ.
хуже может быть лишь прямая вставка из запроса в SQL-выражение.
друзья, давайте просто-напросто ДУМАТЬ.
Вот поэтому разработка через тестирование - выбор профиесионалов.
да здравствует Uint16 :)
да здравствует integer unsigned not null
НЛО прилетело и опубликовало эту надпись здесь
не поможет в случае, если общая сумма >0 так что без проверки никуда
Так надо количества тоже в integer unsigned хранить.
Вы, извините, в базе храните корзину? И что размера базы хватает на всех, кто отменял сессии? или вы не даёте ходить по магазину без регистрации?
Так корзины устаревших сессий удаляются же.
Не проще ли содержимое корзины хранить во временной сессии, чем в базе?
А кому от этого лучше станет?
1. разгрузка базы от ненужных временных данных
2. экономия производительности сервера (или ваш магазин не расчитывается на большую посещаемость?)
Так может всем станет лучше?
2. экономия производительности сервера (или ваш магазин не расчитывается на большую посещаемость?)
Так может всем станет лучше?
А пересылка данных сессии через куки туда-обратно на каждой странице не требует производительности сервера?
Это в php такой тип данных существует?
НЛО прилетело и опубликовало эту надпись здесь
Неужто нынче с профессиональными программерами так туго?
Чем человек больше знает, тем сложнее решения простых проблем. Я бы брал модуль от количества. Видно я мало знаю))
Сомневаюсь, что это — верный путь. Вероятность, что человек, который ввел количество -555 тазиков на самом деле хочет купить 555 тазиков не велика. Скорее всего он проверяет ваш магазин на ошибки или же он безумец.
Большинство решает эту проблему выпадающим списком. Допустим врядли обычный человек будет покупать себе 500 пар туфель, поэтому можно обойтись выпадающим списком от 1 до 10.
Большинство решает эту проблему выпадающим списком. Допустим врядли обычный человек будет покупать себе 500 пар туфель, поэтому можно обойтись выпадающим списком от 1 до 10.
Не, лучше введенное число сравнивать с тем, сколько тазиков есть в наличии и в случае чего выдавать предупреждение, а то вдруг какой-нибудь крупнооптовый клиент захочет купить сразу 555 штук, а мы ему по 10 будем предлагать...
Естественно надо сравнивать. Примерный исход: -555 это ж меньше 10, которые есть на складе значит можно продавать:)
И моё IMHO: крупным клиентов нужно переводить на совершенно иной, гораздо более высокий уровень обслуживания. К интерфейсам это тоже относиться
И моё IMHO: крупным клиентов нужно переводить на совершенно иной, гораздо более высокий уровень обслуживания. К интерфейсам это тоже относиться
НЛО прилетело и опубликовало эту надпись здесь
Но в любом случае нужно проверять значение. Ибо значение выпадающего списка тоже подменить не трудно.
Не думаю, что простой пользователь будет проверять магазин на ошибки. А тот кто будет увидит, что ошибки нет, когда обнаружит в своей корзине 555 тазиков. Выпадающий список конечно хорошо, решает еще одну проблему - ввод текстовых данных в поле "Количество", но все же бывают исключения.
НЛО прилетело и опубликовало эту надпись здесь
Выпадающий список не панацея. Он подойдет только в совсем маленьких интернет-магазинах. Просто следите за своим кодом.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А может сразу при вводе количества (на "onkeypress") не допускать недопустимые символы?
По моему лучше (если есть такая возможность) проверять данные не на сервере, а сразу "на клиенте".
По моему лучше (если есть такая возможность) проверять данные не на сервере, а сразу "на клиенте".
На самом деле, это совершенно тривиальная вещь, которую лично я пишу в ТЗ на автомате. Думаю, что это просто стереотип недавно начавших писать под веб: кажется, что юзер передает нам _переменную_. А на самом деле он передает грязные данные, из которых нам уже нужно получить переменные для дальнейшей работы. Многие просто получая готовый массив/хеш и т.д. из http-запроса забывают про этот момент.
Нужно определить сразу, еще на этапе проектирования, например, что quantity - это натуральное число (не более чем максимальное значение поля в базе - например, int в диапазоне 1..65536). У строк - свои ограничения (по длине, по регэкспу и т.д.).
После чего делать некий метод/функцию/свойство, которое проверяет данные, и в случае несоответствия генерит ошибку.
И не нужно пытаться угадывать что хотел ввести юзер - ни к чему хорошему это не приведет.
Нужно определить сразу, еще на этапе проектирования, например, что quantity - это натуральное число (не более чем максимальное значение поля в базе - например, int в диапазоне 1..65536). У строк - свои ограничения (по длине, по регэкспу и т.д.).
После чего делать некий метод/функцию/свойство, которое проверяет данные, и в случае несоответствия генерит ошибку.
И не нужно пытаться угадывать что хотел ввести юзер - ни к чему хорошему это не приведет.
можно сколько угодно говорить о элементарности ошибок и простоте их решений, но, тем не менее, они бывают у всех. даже у, казалось бы, очень опытных и "бывалых"
Согласен с тем, что на это нужно обращать внимание сообщества. Думаю, это привычка людей которые создавая stand-alone приложения, могут полностью контролировать ввод на уровене интерфейса. Это тоже часто создает узязвимости, но не так и не такие на вебе.
Лично у меня есть свой элемент архитектуры - при получении данных свой accert(), который в случает чего генерит throw.
Использую его всегда, поэтому мне кажется такой подход очевидным :)
Лично у меня есть свой элемент архитектуры - при получении данных свой accert(), который в случает чего генерит throw.
Использую его всегда, поэтому мне кажется такой подход очевидным :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
кстати сам совсем недавно чисто случайно столкнулся с таким багом (фичей?) у самизнаетекого
картинка тут →
картинка тут →
Бля! Да это ж беспредел пошел полный! В натуре, сделайте чтобы новые пользователи не могли сразу добавлять комментарии!
Лично я сюда пришел из-за того, что здесь реально грамотные статьи и обсуждения про IT. Но по ходу скоро все это превратится в помойку. И я думаю, не один я так думаю.
По сути указав 555 тазиков вы заказываете на на поставку у магазина.
тоесть -555 тазиков - это вы должны поставить магазину тазики. тоесть знак - будет значит тазики с вашей стороны, в то время как + есть тазики со стороны магазина.
помоему тут даже думать не надо, просто - это обратный заказ по отношению к продавцу, тоесть не на покупку, а на продажу.
тоесть -555 тазиков - это вы должны поставить магазину тазики. тоесть знак - будет значит тазики с вашей стороны, в то время как + есть тазики со стороны магазина.
помоему тут даже думать не надо, просто - это обратный заказ по отношению к продавцу, тоесть не на покупку, а на продажу.
Не совсем верно.
Логика магазина реализована только на продажу. Да и сдачу он возвращать не будет(тут именно это и подразумевается технически), это тоже спрограммировано. Так как это не прилавок(offline-магазин), где вы даете купюру, большую, чем цена, и вам возвращают остаток.
Логика магазина реализована только на продажу. Да и сдачу он возвращать не будет(тут именно это и подразумевается технически), это тоже спрограммировано. Так как это не прилавок(offline-магазин), где вы даете купюру, большую, чем цена, и вам возвращают остаток.
хм, тогда думаем просто - почему бы нам не обратиться в общество по защите прав потребителя и таким образом не выманить из магазина пару миллиончиков???
а на каком основании? за то, что у них баги в программе? от этого у вас нервный срыв был?
да очень просто:
я сделал заказ, мне написало, что магазин мне должен деньги. пусть отдает.
в америке это закон прекрасно работает - если по ошибке веб-мастера цена на продукт оказалась 1$ и кто-то успел по этой цене заказать 100 единиц продукта, то магазин просто обязан их поставить по цене 1$ за штуку.
я сделал заказ, мне написало, что магазин мне должен деньги. пусть отдает.
в америке это закон прекрасно работает - если по ошибке веб-мастера цена на продукт оказалась 1$ и кто-то успел по этой цене заказать 100 единиц продукта, то магазин просто обязан их поставить по цене 1$ за штуку.
Тогда это указанный вначале обмен с доплатой - вы им пять синих тазиков и 9500р, а они вам один красный.
Гениально. Я давно хотел проверить парочку магазинов на этот счёт, но, к своему стыду, лень-матушка вперёд родилась.
Главное - чтобы программист который выполняет заказ был параноиком ;)
тогда будут проверки на что угодно в коде.
тогда будут проверки на что угодно в коде.
Я параноик. Так и не смог заставить программиста сделать проверку на буквы в корзине )
А так все как и рекомендовано: http://www.neozon.ru
А так все как и рекомендовано: http://www.neozon.ru
На самом деле мелкий баг, подобных кучи.
Просто нужно, чтобы тестировал продукт не сам программист, а отдельный человек, чья задача выявлять баги, и писать багрепорты.
Просто нужно, чтобы тестировал продукт не сам программист, а отдельный человек, чья задача выявлять баги, и писать багрепорты.
Я сейчас глупость скажу, потому как не программер. А нельзя так сделать, чтобы скрипт тупо превращал любую величину из конкретного инпута в положительную? Ну написал покупатель -555, а в корзине пересчитывалось бы как 555. Еще можно на яве сделать, чтобы нельзя было писать определенные знаки (хотя это "от дураков" защита, а не от шутников).
Сугубо диллетантское мнение, конечно...
Сугубо диллетантское мнение, конечно...
Угу, выше кто-то уже предлагал брать абсолютное значение.
Я вам объясню почему это не совсем правильно. Дело в том, что кнопка "-" очень часто стоит рядом с кнопками цифр. Предположим, что покупатель магазина хотел набрать число 92. Он опечатался и у него получилось -2. Что происходит: скрипт конвертирует -2 в 2 или просто не дает вбить минус, выходит число 2. Если пользователь невнимателен, то ему привезут 2 единицы товара вместо 9-ти.
Вывод: всегда выдавайте сообщение о неверном формате введенных данных пользователю: "Вы ввели отрицательное количество единиц товара. Проверьте, пожалуйста, введенную величину.".
Вывод: всегда выдавайте сообщение о неверном формате введенных данных пользователю: "Вы ввели отрицательное количество единиц товара. Проверьте, пожалуйста, введенную величину.".
а в движке XT:Commerce такого бага нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ваш заказ -555 тазиков на сумму -55500 руб.