Это справедливо для соответствующей задачи, но в данном случае величина диапазона скорее понятие психологическое. Администратору не нужно знать точное значение минимума и максимума цен, так как это может выглядеть не вполне красиво, например, 21545-112258 рублей.
Можно и здесь додумать и округлить до подходящей сотни или тысячи, как это делается при перемещении ползунка, но это решение, которое, как показывает практика, вызывает вопрос «я точно знаю, что у меня самый дешевый товар стоит 21545 рублей, а почему у вас показывает 21000?»
Немного отвлекаясь, можно подумать, что приятнее для администратора, но в таких случаях, полагаю, лучше спросить у него.
Спасибо, эти минусы действительно существенны. Вмешаться в закрытый компонент без исходников проблематично, а в данном случае и не нужно. Проще написать заново, хотя, если трудовые затраты сопоставимы, а результат соответствует требуемому, можно выбирать то, что больше нравится.
Но безусловно, опыт и подготовка решают многое.
А вот это лучший вариант для хранения параметров. Если бы были только эти настройки, так и стоило бы сделать. К сожалению, есть и другие. Объяснить конечному администратору сайта назначение настроек легче, когда они сконцентрированы в одном месте, а не разбиты по модулям. Если же настроек слишком много, опять-таки легче объяснить их назначение, когда страницы с ними находятся в одном разделе. С точки зрения наполняющего контент, так проще, хотя идеологически верно было бы следовать рекомендациям Umisoft и указанному вами варианту.
Администратор хочет именно править значения границ диапазона, так как цены меняются. Если сегодня в магазине есть товары стоимостью от 10000 до 50000 рублей, то через некоторое время стоимость может варьироваться, например, от 20000 до 100000. Это не часто, но происходит. В этом случае администратору править проще в административной панели свойства страницы настроек.
Собственно, протокол Usel используется для поиска как раз страницы настроек, но администратора сайта этот вопрос не должен беспокоить.
Согласен, решение должно соответствовать задаче. Но вопрос остается открытым, как сверстать ценовой диапазон «правильно» под старые браузеры в приемлемый срок? Моё решение не оптимально, но работает. Хотелось бы получить подсказку помимо указания 10-летнего опыта верстки. Неужели вам не приходится верстать с учетом устаревших версий?
Это мое личное решение данного вопроса. Увы, но под IE7 и Firefox 3.6 мне действительно трудно сверстать подобный блок ползунков на html5, в то время как нарисовать и запрограммировать в среде Flash оказалось проще. Так что учиться мне ещё следует действительно много. Хотя мне интересно, действительно ли данная флешка с ползунками может нагрузить компьютер, способный нести современные браузеры, сильнее аналогичных jQuery-компонентов, если учесть, что для последних нужна ещё сама библиотека jQuery. Вопрос интересный, так как в этом проекте jQuery всё равно используется и мешает только проблема кроссбраузерности.
К сожалению, это не совсем то, что нужно. В список обязательных браузеров входит IE7, а в нём работа этих компонентов немного отличается от остальных. Плюс фактор времени. Подготовить такую флешку в нужном дизайне и кодом обработки значений — 1 час. Найти подходящую библиотеку и адаптировать под то, что нужно — не меньше. Плюс простота использования: один четырехкилобайтовый swf-файл против скрипта компонента, стилей и изображений.
Можно и здесь додумать и округлить до подходящей сотни или тысячи, как это делается при перемещении ползунка, но это решение, которое, как показывает практика, вызывает вопрос «я точно знаю, что у меня самый дешевый товар стоит 21545 рублей, а почему у вас показывает 21000?»
Немного отвлекаясь, можно подумать, что приятнее для администратора, но в таких случаях, полагаю, лучше спросить у него.
Но безусловно, опыт и подготовка решают многое.
Собственно, протокол Usel используется для поиска как раз страницы настроек, но администратора сайта этот вопрос не должен беспокоить.