Комментарии 28
Почему бы для ползунков не использовать нечто вроде jQuery UI — Slider? Зачем тут флеш?
К сожалению, это не совсем то, что нужно. В список обязательных браузеров входит IE7, а в нём работа этих компонентов немного отличается от остальных. Плюс фактор времени. Подготовить такую флешку в нужном дизайне и кодом обработки значений — 1 час. Найти подходящую библиотеку и адаптировать под то, что нужно — не меньше. Плюс простота использования: один четырехкилобайтовый swf-файл против скрипта компонента, стилей и изображений.
Конечно флеш хорошо, но я поддерживаю estudante, такие вещи лучше делать на JS (если не изменяет память, на яндекс.маркете с незапамятных времен работают такие ползунки). Как говорится, стоит смотреть в будущее.
Из минусов вижу:
— закрытый компонент на флеше
— сложности в модификации дизайна (в будущем?)
— все равно присутствует прослойка на JS
— управление при помощи TAB? (jQuery UI slider позволяет переводить фокус на ползунки)
При желании и соответствующем опыте данное решение можно реализовать при помощи jQuery UI Slider за менее, чем час, с уникальным дизайном, работающем в IE7.
Из минусов вижу:
— закрытый компонент на флеше
— сложности в модификации дизайна (в будущем?)
— все равно присутствует прослойка на 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-летнего опыта верстки. Неужели вам не приходится верстать с учетом устаревших версий?
>когда все отказываются от флеша, так как общеизвестно, что данная технология нещадна к ресурсам клиентского компьютера и ранее была приемлема… когда браузеры еще не имели поддержки html5 и css3…
Отвечу на этот и другие комментарии человека, которому 10-ти летний опыт вёрстки позволяет допустить 3 орфографические ошибки в одном предложении, открыв несколько простых истин:
1) HTML и CSS — это только языки разметки и описания внешнего вида документа (в 5-ой и 3-ей версиях соответственно для вас они вышли за эти рамки?). Напомню, всё это гоняется от сервера к клиенту в текстовом виде.
2) jQuery — библиотека JavaScript. «Тормозит яваскрипт? А давайте завернём всё это в класс!», — словно бы истошно кричит наш автор.
И действительно, 10-ти летний опыт подсказывает ему, что гонять к клиенту по малейшей нужде полтора десятка килобайт помогает ускорить загрузку страниц, а те же пара используемых функций, но завёрнутые в класс, сильно ускорят их выполнение. Также опыт подсказывает ему, что интерпретация скриптов в текстовом виде происходит гораздо быстрее выполнения заранее скомпилированного и во много раз меньшего по размеру байт-кода, который исполняется точно также по событию. В его понимании он постоянно молотит (видимо, травма детства, полученная при попытке написать что-то на as3 используя опыт верстальщика). Итого, автор видит несомненное преимущество загрузки многочисленных текстовых данных разметки, оформления, библиотек (которые он использует на все 100% на каждой странице), его очаровывает многочасовой секс, в котором достигается однообразное отображение в каждом браузере.
Для интерактивных элементов, подобных описанному в статье фильтру (а если что-то более сложное?..), всё это много лучше чем загрузить небольшой байт-код для виртуальной машины flash-плеера (не буду упоминать насколько он распространён и что он присутствует по-умолчанию во многих браузерах).
Отвечу на этот и другие комментарии человека, которому 10-ти летний опыт вёрстки позволяет допустить 3 орфографические ошибки в одном предложении, открыв несколько простых истин:
1) HTML и CSS — это только языки разметки и описания внешнего вида документа (в 5-ой и 3-ей версиях соответственно для вас они вышли за эти рамки?). Напомню, всё это гоняется от сервера к клиенту в текстовом виде.
2) jQuery — библиотека JavaScript. «Тормозит яваскрипт? А давайте завернём всё это в класс!», — словно бы истошно кричит наш автор.
И действительно, 10-ти летний опыт подсказывает ему, что гонять к клиенту по малейшей нужде полтора десятка килобайт помогает ускорить загрузку страниц, а те же пара используемых функций, но завёрнутые в класс, сильно ускорят их выполнение. Также опыт подсказывает ему, что интерпретация скриптов в текстовом виде происходит гораздо быстрее выполнения заранее скомпилированного и во много раз меньшего по размеру байт-кода, который исполняется точно также по событию. В его понимании он постоянно молотит (видимо, травма детства, полученная при попытке написать что-то на as3 используя опыт верстальщика). Итого, автор видит несомненное преимущество загрузки многочисленных текстовых данных разметки, оформления, библиотек (которые он использует на все 100% на каждой странице), его очаровывает многочасовой секс, в котором достигается однообразное отображение в каждом браузере.
Для интерактивных элементов, подобных описанному в статье фильтру (а если что-то более сложное?..), всё это много лучше чем загрузить небольшой байт-код для виртуальной машины flash-плеера (не буду упоминать насколько он распространён и что он присутствует по-умолчанию во многих браузерах).
Вы тоже не блещите ясностью изложения. Я программирую и сервер и клиент и в данном случае эта важно так как идет разговор о доработке на конкретном ПО. Вы же держитесь за свой флеш, когда он тут является пятым колесом. Я пытаюсь донести мысль гораздо проще и если бы вы читали внимательней то поняли меня: на проекте УЖЕ используется jQuery! а теперь скажите, загрузка 5 строк яваскрипта в данном случае уступает запуску виртуальной машины, которая без этого не используется?
Поехали дальше, разговор идет о кроссбраузерности, вам известна основная цель разрбокти jQuery? Вам известно о jQueryUI, которая содержит виджеты-примитивы рещающие описанную автором задачу?
Так что же вы хотели доказать? Мою неграмотность? Вы реально считаете что правила разметки и русского языка пересекаются? Упоминать о распространённости виртуальной машины просто смешно, вы же не хотите сказать что поддержка Flash шире чем JS в нынесуществующих браузерах?
Поехали дальше, разговор идет о кроссбраузерности, вам известна основная цель разрбокти jQuery? Вам известно о jQueryUI, которая содержит виджеты-примитивы рещающие описанную автором задачу?
Так что же вы хотели доказать? Мою неграмотность? Вы реально считаете что правила разметки и русского языка пересекаются? Упоминать о распространённости виртуальной машины просто смешно, вы же не хотите сказать что поддержка Flash шире чем JS в нынесуществующих браузерах?
HTML и CSS — это только языки разметки и описания внешнего вида документа (в 5-ой и 3-ей версиях соответственно для вас они вышли за эти рамки?). Напомню, всё это гоняется от сервера к клиенту в текстовом виде.
Вообще-то html5 — это целый стек технологий, в то время как html — это просто язык разметки.
Ваши слова не лишены смысла. Но владельцы мобильных устройств без поддержки flash совсем не поймут о чем вы.
В современных реалиях подобная мелочь как jQuery/jQuery UI если и будет вас беспокоить, то только как статика, которую нужно отдать.
В современных реалиях подобная мелочь как jQuery/jQuery UI если и будет вас беспокоить, то только как статика, которую нужно отдать.
пушкой по воробьям.
как написал estudante, есть jQuery UI.
кстати, а о пользователях продукции фирмы apple вы подумали?)
как написал estudante, есть jQuery UI.
кстати, а о пользователях продукции фирмы apple вы подумали?)
НЛО прилетело и опубликовало эту надпись здесь
Велосипедище! Да еще и 5-ти колесный…
А почему бы не запрашивать минимальную и максимальную цены из базы сразу для конкретного раздела? Два небольших Usel и администратор лишен головной боли. Или я чего-то не понял?
Администратор хочет именно править значения границ диапазона, так как цены меняются. Если сегодня в магазине есть товары стоимостью от 10000 до 50000 рублей, то через некоторое время стоимость может варьироваться, например, от 20000 до 100000. Это не часто, но происходит. В этом случае администратору править проще в административной панели свойства страницы настроек.
Собственно, протокол Usel используется для поиска как раз страницы настроек, но администратора сайта этот вопрос не должен беспокоить.
Собственно, протокол Usel используется для поиска как раз страницы настроек, но администратора сайта этот вопрос не должен беспокоить.
Вы бы могли автоматом запрашивать минимальную и максимальную цены, и с помощью юсел сделать гибкую выборку. Допустим есть товары от 10000 до 50000 и вдруг все что в диапазоне 10000-20000 распродаются, в результате этот диапазон становиться бесполезным. Можно написать выборку которая автоматом выбирает минимальную цену то есть 21000 и так же максимальную. Это логически более верно, представьте что есть несколько совершенно различных каталогов в рамках одного интернет магазина: двери и коробки, ручки, доборы к ним. Администратору придется отслеживать цены на всех категориях. А так все автоматически и без головной боли.
Конечно для решения поставленной задачи возможно достаточно и такого решения, но я как то привык все делать максимально универсально и максимально близко к идеологии системы:)
Конечно для решения поставленной задачи возможно достаточно и такого решения, но я как то привык все делать максимально универсально и максимально близко к идеологии системы:)
Это справедливо для соответствующей задачи, но в данном случае величина диапазона скорее понятие психологическое. Администратору не нужно знать точное значение минимума и максимума цен, так как это может выглядеть не вполне красиво, например, 21545-112258 рублей.
Можно и здесь додумать и округлить до подходящей сотни или тысячи, как это делается при перемещении ползунка, но это решение, которое, как показывает практика, вызывает вопрос «я точно знаю, что у меня самый дешевый товар стоит 21545 рублей, а почему у вас показывает 21000?»
Немного отвлекаясь, можно подумать, что приятнее для администратора, но в таких случаях, полагаю, лучше спросить у него.
Можно и здесь додумать и округлить до подходящей сотни или тысячи, как это делается при перемещении ползунка, но это решение, которое, как показывает практика, вызывает вопрос «я точно знаю, что у меня самый дешевый товар стоит 21545 рублей, а почему у вас показывает 21000?»
Немного отвлекаясь, можно подумать, что приятнее для администратора, но в таких случаях, полагаю, лучше спросить у него.
В этом случае администратору править проще в административной панели свойства страницы настроек.
Показал этот текст заказчикам, которым я решал задачи по автоматизации — дружно посмеялись. Дико. Дикая у вас работа. Хотя, возможно, только при использовании таких подходов этот 'администратор' и будет нужен.
Уж лучше вынести правила округления в настройки и ничего что левая и правая границы не будут фактически существовать(12000 вместо 12133 и 22200 вместо 22293) — все равно у нас операция 'МЕЖДУ'. Только шаг продумать, чтобы клиент не смог сам себя в угол загнать( диапазон от 12000 до 12132 например).
И если уж хранить значения минимальной и максимальной цен то логичнее всего это делать в «реестре» юми. И вывести настройки в конфигурацию модуля. Ужасный конечно костыль получился…
А вот это лучший вариант для хранения параметров. Если бы были только эти настройки, так и стоило бы сделать. К сожалению, есть и другие. Объяснить конечному администратору сайта назначение настроек легче, когда они сконцентрированы в одном месте, а не разбиты по модулям. Если же настроек слишком много, опять-таки легче объяснить их назначение, когда страницы с ними находятся в одном разделе. С точки зрения наполняющего контент, так проще, хотя идеологически верно было бы следовать рекомендациям Umisoft и указанному вами варианту.
Заебали со своей рекламой юми.
Юми х flash — это типа как минус на минус должен плюс получиться?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взаимодействие Umi.CMS и Flash посредством функций Javascript