Комментарии 28
К сожалению, это не совсем то, что нужно. В список обязательных браузеров входит IE7, а в нём работа этих компонентов немного отличается от остальных. Плюс фактор времени. Подготовить такую флешку в нужном дизайне и кодом обработки значений — 1 час. Найти подходящую библиотеку и адаптировать под то, что нужно — не меньше. Плюс простота использования: один четырехкилобайтовый swf-файл против скрипта компонента, стилей и изображений.
Конечно флеш хорошо, но я поддерживаю estudante, такие вещи лучше делать на JS (если не изменяет память, на яндекс.маркете с незапамятных времен работают такие ползунки). Как говорится, стоит смотреть в будущее.

Из минусов вижу:
— закрытый компонент на флеше
— сложности в модификации дизайна (в будущем?)
— все равно присутствует прослойка на JS
— управление при помощи TAB? (jQuery UI slider позволяет переводить фокус на ползунки)

При желании и соответствующем опыте данное решение можно реализовать при помощи jQuery UI Slider за менее, чем час, с уникальным дизайном, работающем в IE7.
Спасибо, эти минусы действительно существенны. Вмешаться в закрытый компонент без исходников проблематично, а в данном случае и не нужно. Проще написать заново, хотя, если трудовые затраты сопоставимы, а результат соответствует требуемому, можно выбирать то, что больше нравится.
Но безусловно, опыт и подготовка решают многое.
Интересно, а с Gnash работать будет? А то не вижу ссылку на демо, чтобы проверить.
это бред какой-то дикий!!! когда все отказываются от флеша, так как общеизвестно, что данная технология не щадна к рессурсам клиентского компьютера и ранее была приемлима из-за уникальной возможности создавать любые визуальные решения, когда браузеры еще не имели поддержки html5 и css3 (да их и не было еще)!!! Мне как человеку с более чем 10-ти летним опытом верстки ваше решение кажется просто неадекватным. Наддеюсь это лишь ваше виденье вопроса, а не UMI подталкивает порядочных людей к таким маневрам.
Это мое личное решение данного вопроса. Увы, но под IE7 и Firefox 3.6 мне действительно трудно сверстать подобный блок ползунков на html5, в то время как нарисовать и запрограммировать в среде Flash оказалось проще. Так что учиться мне ещё следует действительно много. Хотя мне интересно, действительно ли данная флешка с ползунками может нагрузить компьютер, способный нести современные браузеры, сильнее аналогичных jQuery-компонентов, если учесть, что для последних нужна ещё сама библиотека jQuery. Вопрос интересный, так как в этом проекте jQuery всё равно используется и мешает только проблема кроссбраузерности.
давайте же все будем ходить за хлебом на ходулях вставленных в коньки закрепленные на сноуборде! «действительно ли данная флешка с ползунками может нагрузить компьютер, способный нести современные браузеры,» — а я смотрю вы щедрый) т.е. нагрузка не сравнима, если jQuery уже есть к тому же. Вы можете лицезреть все наглядно в friebug->net(сеть), предварительно замерив в нем инициализацию своей… своего решения, а потом уже переписать все правильно и еще раз замерить!
Согласен, решение должно соответствовать задаче. Но вопрос остается открытым, как сверстать ценовой диапазон «правильно» под старые браузеры в приемлемый срок? Моё решение не оптимально, но работает. Хотелось бы получить подсказку помимо указания 10-летнего опыта верстки. Неужели вам не приходится верстать с учетом устаревших версий?
jQuery UI, как jQuery кросбраузерна, об этом написано, полная поддержка вплоть до ие6.
>когда все отказываются от флеша, так как общеизвестно, что данная технология нещадна к ресурсам клиентского компьютера и ранее была приемлема… когда браузеры еще не имели поддержки html5 и css3…

Отвечу на этот и другие комментарии человека, которому 10-ти летний опыт вёрстки позволяет допустить 3 орфографические ошибки в одном предложении, открыв несколько простых истин:
1) HTML и CSS — это только языки разметки и описания внешнего вида документа (в 5-ой и 3-ей версиях соответственно для вас они вышли за эти рамки?). Напомню, всё это гоняется от сервера к клиенту в текстовом виде.
2) jQuery — библиотека JavaScript. «Тормозит яваскрипт? А давайте завернём всё это в класс!», — словно бы истошно кричит наш автор.

И действительно, 10-ти летний опыт подсказывает ему, что гонять к клиенту по малейшей нужде полтора десятка килобайт помогает ускорить загрузку страниц, а те же пара используемых функций, но завёрнутые в класс, сильно ускорят их выполнение. Также опыт подсказывает ему, что интерпретация скриптов в текстовом виде происходит гораздо быстрее выполнения заранее скомпилированного и во много раз меньшего по размеру байт-кода, который исполняется точно также по событию. В его понимании он постоянно молотит (видимо, травма детства, полученная при попытке написать что-то на as3 используя опыт верстальщика). Итого, автор видит несомненное преимущество загрузки многочисленных текстовых данных разметки, оформления, библиотек (которые он использует на все 100% на каждой странице), его очаровывает многочасовой секс, в котором достигается однообразное отображение в каждом браузере.
Для интерактивных элементов, подобных описанному в статье фильтру (а если что-то более сложное?..), всё это много лучше чем загрузить небольшой байт-код для виртуальной машины flash-плеера (не буду упоминать насколько он распространён и что он присутствует по-умолчанию во многих браузерах).
Вы тоже не блещите ясностью изложения. Я программирую и сервер и клиент и в данном случае эта важно так как идет разговор о доработке на конкретном ПО. Вы же держитесь за свой флеш, когда он тут является пятым колесом. Я пытаюсь донести мысль гораздо проще и если бы вы читали внимательней то поняли меня: на проекте УЖЕ используется jQuery! а теперь скажите, загрузка 5 строк яваскрипта в данном случае уступает запуску виртуальной машины, которая без этого не используется?
Поехали дальше, разговор идет о кроссбраузерности, вам известна основная цель разрбокти jQuery? Вам известно о jQueryUI, которая содержит виджеты-примитивы рещающие описанную автором задачу?
Так что же вы хотели доказать? Мою неграмотность? Вы реально считаете что правила разметки и русского языка пересекаются? Упоминать о распространённости виртуальной машины просто смешно, вы же не хотите сказать что поддержка Flash шире чем JS в нынесуществующих браузерах?
HTML и CSS — это только языки разметки и описания внешнего вида документа (в 5-ой и 3-ей версиях соответственно для вас они вышли за эти рамки?). Напомню, всё это гоняется от сервера к клиенту в текстовом виде.

Вообще-то html5 — это целый стек технологий, в то время как html — это просто язык разметки.
Ваши слова не лишены смысла. Но владельцы мобильных устройств без поддержки flash совсем не поймут о чем вы.
В современных реалиях подобная мелочь как jQuery/jQuery UI если и будет вас беспокоить, то только как статика, которую нужно отдать.
пушкой по воробьям.
как написал estudante, есть jQuery UI.
кстати, а о пользователях продукции фирмы apple вы подумали?)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А почему бы не запрашивать минимальную и максимальную цены из базы сразу для конкретного раздела? Два небольших Usel и администратор лишен головной боли. Или я чего-то не понял?
Администратор хочет именно править значения границ диапазона, так как цены меняются. Если сегодня в магазине есть товары стоимостью от 10000 до 50000 рублей, то через некоторое время стоимость может варьироваться, например, от 20000 до 100000. Это не часто, но происходит. В этом случае администратору править проще в административной панели свойства страницы настроек.
Собственно, протокол Usel используется для поиска как раз страницы настроек, но администратора сайта этот вопрос не должен беспокоить.
Вы бы могли автоматом запрашивать минимальную и максимальную цены, и с помощью юсел сделать гибкую выборку. Допустим есть товары от 10000 до 50000 и вдруг все что в диапазоне 10000-20000 распродаются, в результате этот диапазон становиться бесполезным. Можно написать выборку которая автоматом выбирает минимальную цену то есть 21000 и так же максимальную. Это логически более верно, представьте что есть несколько совершенно различных каталогов в рамках одного интернет магазина: двери и коробки, ручки, доборы к ним. Администратору придется отслеживать цены на всех категориях. А так все автоматически и без головной боли.
Конечно для решения поставленной задачи возможно достаточно и такого решения, но я как то привык все делать максимально универсально и максимально близко к идеологии системы:)
Это справедливо для соответствующей задачи, но в данном случае величина диапазона скорее понятие психологическое. Администратору не нужно знать точное значение минимума и максимума цен, так как это может выглядеть не вполне красиво, например, 21545-112258 рублей.

Можно и здесь додумать и округлить до подходящей сотни или тысячи, как это делается при перемещении ползунка, но это решение, которое, как показывает практика, вызывает вопрос «я точно знаю, что у меня самый дешевый товар стоит 21545 рублей, а почему у вас показывает 21000?»

Немного отвлекаясь, можно подумать, что приятнее для администратора, но в таких случаях, полагаю, лучше спросить у него.
В этом случае администратору править проще в административной панели свойства страницы настроек.


Показал этот текст заказчикам, которым я решал задачи по автоматизации — дружно посмеялись. Дико. Дикая у вас работа. Хотя, возможно, только при использовании таких подходов этот 'администратор' и будет нужен.
Уж лучше вынести правила округления в настройки и ничего что левая и правая границы не будут фактически существовать(12000 вместо 12133 и 22200 вместо 22293) — все равно у нас операция 'МЕЖДУ'. Только шаг продумать, чтобы клиент не смог сам себя в угол загнать( диапазон от 12000 до 12132 например).
И если уж хранить значения минимальной и максимальной цен то логичнее всего это делать в «реестре» юми. И вывести настройки в конфигурацию модуля. Ужасный конечно костыль получился…
А вот это лучший вариант для хранения параметров. Если бы были только эти настройки, так и стоило бы сделать. К сожалению, есть и другие. Объяснить конечному администратору сайта назначение настроек легче, когда они сконцентрированы в одном месте, а не разбиты по модулям. Если же настроек слишком много, опять-таки легче объяснить их назначение, когда страницы с ними находятся в одном разделе. С точки зрения наполняющего контент, так проще, хотя идеологически верно было бы следовать рекомендациям Umisoft и указанному вами варианту.
Юми х flash — это типа как минус на минус должен плюс получиться?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.