Comments 139
Красиво!
Недавно решал похожую задачку — нужно было сделать каталог для интернет-магазина, чтобы работал быстро у пользователей с очень медленным и ненадежным интернетом. В результате сделал на Silverlight с возможностью оффлайн работы. Хотя это, конечно, не так круто как HTML5. :)
Недавно решал похожую задачку — нужно было сделать каталог для интернет-магазина, чтобы работал быстро у пользователей с очень медленным и ненадежным интернетом. В результате сделал на Silverlight с возможностью оффлайн работы. Хотя это, конечно, не так круто как HTML5. :)
На самом деле, в демке HTML5 нигде не используется. Я отметил это на картинке как безусловный атрибут в будущем.
Отлично, теперь пользователям с медленным и ненадежным интернетом нужно качать Silverlight.
Я бы закрыл вкладку после того, как мне бы предложили скачать и установить сильверлайт. И уверен, так бы сделали (и наверное сделали) 95% пользователей.
Пользователь приходит в магазин за товаром, и хочет его видеть как можно быстрее и заказать как можно проще.
Пользователь приходит в магазин за товаром, и хочет его видеть как можно быстрее и заказать как можно проще.
Естественно, это не замена обычного каталога, а только дополнение для тех, кому это нужно. В отдельном разделе сайта есть страничка с описанием: попробуйте нашу программу для работы с сайтом, это дает такие-то преимущества, сильверлайт можно скачать здесь и т.д. Целевая аудитория — мелкооптовые покупатели из регионов, которые закупают в этом интернет-магазине товары и продают у себя.
Увы, что бы там не говорила Microsoft, до распространенности флэша сильверлайту еще очень и очень далеко.
Увы, что бы там не говорила Microsoft, до распространенности флэша сильверлайту еще очень и очень далеко.
Мне так говорят многие знакомые, но про джаваскрипт. «У меня стоит noscript, если я увижу, что сайт требует джаваскрипт — я закрываю вкладку.» А мне приходится извращаться из-за таких дебилов.
пользователей мобильных телефонов тоже дебилами называете? progressive enhancement никто не отменял.
для пользователей моб. телефонов делается отдельная версия сайта.
т.е. это уже три версии сайта?
— мобильная
— для десктопных браузеров без javascript/допотопных браузеров
— для новейших браузеров с поддержкой javascript
ещё раз повторю — progressive enhancement придуман уже давно. очень жаль, что немногие веб разработчики правильно понимают его суть. а это между прочим основа веба — как донести свой контент до миллионной аудитории, разнесенной в пространстве и времени.
— мобильная
— для десктопных браузеров без javascript/допотопных браузеров
— для новейших браузеров с поддержкой javascript
ещё раз повторю — progressive enhancement придуман уже давно. очень жаль, что немногие веб разработчики правильно понимают его суть. а это между прочим основа веба — как донести свой контент до миллионной аудитории, разнесенной в пространстве и времени.
мобильную версию, кстати, надо тоже не забыть поделить на:
— для примитивных смартфонов
— для мобильного вебкита
— нативные клиенты для iphone и android
всё это сейчас в моде. и в корне неверно. сами же создаём себе сложности.
— для примитивных смартфонов
— для мобильного вебкита
— нативные клиенты для iphone и android
всё это сейчас в моде. и в корне неверно. сами же создаём себе сложности.
Вы про progressive enhancement расскажите пользователям ie6 :)
Понятно, что хочется сделать один раз, чтобы в соответствии с вышеуказанным концепцией все получили доступ к данным в одинаково удобном виде, вне зависимости от типа девайса и софта.
Но, на данный момент, это невозможно.
Понятно, что хочется сделать один раз, чтобы в соответствии с вышеуказанным концепцией все получили доступ к данным в одинаково удобном виде, вне зависимости от типа девайса и софта.
Но, на данный момент, это невозможно.
> все получили доступ к данным в одинаково удобном виде
ну я же говорю — мало кто понимает концепцию. потому что лень разобраться. и отсюда фразы типа «на данный момент, это невозможно»
ну я же говорю — мало кто понимает концепцию. потому что лень разобраться. и отсюда фразы типа «на данный момент, это невозможно»
en.wikipedia.org/wiki/Progressive_enhancement
enhanced layout is provided by externally linked CSS
enhanced behavior is provided by unobtrusive, externally linked JavaScript
end user browser preferences are respected
как ни крути, под каждый девай создаётся отдельный «слой» css/js etc.
enhanced layout is provided by externally linked CSS
enhanced behavior is provided by unobtrusive, externally linked JavaScript
end user browser preferences are respected
как ни крути, под каждый девай создаётся отдельный «слой» css/js etc.
Вы про progressive enhancement расскажите пользователям ie6 :)
Firefox && Chrome && IE8 >> IE7 >> IE6 — regressive hacking ;)
Я имею в виду пользователей, сознательно использующих noscript и говорящих «если сайт использует джаваскрипт, то он — не тру, говно, и вообще мерзость. Пользоваться этой дрянью не буду.»
вы знаете что у простых пользователей в большинстве сильверлайт уже установлен. ставится с винапдейтами
На хабре много «пользователе» которые априори ненавидят технологии silverlight и flash.
Им плевать, что у большинства пользователей эти плагины уже стоят.
Им плевать, что у большинства пользователей эти плагины уже стоят.
А за что ненавидят? И вообще, как можно ненавидеть технологию? С головой поссорились?
На хабре 80% так или иначе адепты новой Империи Зла (смотрите Хабраиндекс).
Поэтому продукты от старой — ненавидятся автоматом :)
Поэтому продукты от старой — ненавидятся автоматом :)
за то, что её приходиться устанавливать.
Пример google gears — она не критична нигде, где я видел её использование, в хроме она идет в коробке и я ей рад и пользуюсь.
Но когда я пользовался мозиллой я ненавидел gears потому, что она орала о несовместимости и толком не работала.
Гугл распространяет свои геарс, но не навязывает их нету — так нету, но с геарс быстрее — так было написано на всех сайтах, где оно применялось из тех, которые я видел.
Что же делает Флеш или Сильверлайт? «Для просмотра установите флеш» «Для просмотра потребуется сильврлайт»
Причем это даже не линукс, winXP — там последний флешплеер поддерживается только хромом.
А теперь давай подумаем, на кой мне изловчатся в установке непонятного софта на машину, только для того, что б просмотреть сайт метрополитена?
Пример google gears — она не критична нигде, где я видел её использование, в хроме она идет в коробке и я ей рад и пользуюсь.
Но когда я пользовался мозиллой я ненавидел gears потому, что она орала о несовместимости и толком не работала.
Гугл распространяет свои геарс, но не навязывает их нету — так нету, но с геарс быстрее — так было написано на всех сайтах, где оно применялось из тех, которые я видел.
Что же делает Флеш или Сильверлайт? «Для просмотра установите флеш» «Для просмотра потребуется сильврлайт»
Причем это даже не линукс, winXP — там последний флешплеер поддерживается только хромом.
А теперь давай подумаем, на кой мне изловчатся в установке непонятного софта на машину, только для того, что б просмотреть сайт метрополитена?
Раз вы говорите о WinXP, то Мозиллу и Хром вам тоже пришлось установить. Зачем вы это сделали, если в WinXP уже из коробки есть IE? Значит, у вас были причины их установить.
Люди, у которых есть необходимость в работе с сайтами, требующими флеш или сильверлайт, просто ставят их и не парятся.
Это просто технологии. Они имеют свою применяемость, а владельцы сайта выбрали эти технологии. Вы можете ненавидеть этих людей, но причём здесь флэш или сильверлайт?
Люди, у которых есть необходимость в работе с сайтами, требующими флеш или сильверлайт, просто ставят их и не парятся.
Это просто технологии. Они имеют свою применяемость, а владельцы сайта выбрали эти технологии. Вы можете ненавидеть этих людей, но причём здесь флэш или сильверлайт?
Интересно, что уже два часа прошло, а про линукс так и не сказали вам. Говорю!
Аа… «у простых пользователей», извините.
А что, простые пользователи не в состоянии использовать какой-нибудь Linux?
Причем тут не в состоянии? Просто если вы, как и я после отправки первого своего камента, сабж перечитаете, то поймете, что речь идет о подавляющем большинстве. И в данном контексте «простой пользователь» — формулировка без капли неприязни или чего-то такого. Имеется ввиду человек использующий самый распространенный способ получения информации/технологию. Есть 100 500 статистик где наглядно показано, что линуксу 1% «десктопа» достается.
Да и вообще чего тут говорить… Внимательнее читайте, раз решили придираться.
Да и вообще чего тут говорить… Внимательнее читайте, раз решили придираться.
Ubuntu популярна, её всё чаще ставят знакомым, родным, близким. Что касается «подавляющего большинства», такой формулировки я не увидел. И да, вы написали такой длинный возмущенный комментарий, что я на всякий случай скажу — минусовал не я.
Да за минусы я не парюсь, я не из активных пользователей сайта (хотя подумал что вы конечно :) ). Так и знал, что покажется что я возмущен, просто на хабре часто через 2-3 дня когда про тему забыли, кто нибудь напишет странный оффтоп придравшись к какому нибудь камменту, от которого пользы 0.
Кстати, я бы только был счастлив если бы людей использующих убунту, называли простыми пользователями. Но нам до этого далеко.
У меня включен Flash Blocker потому что флешь плагин течёт. А на большинстве сайтов флеш это баннер. Тоже самое с MonoLight. Поэтом если у меня есть выбор сайт на СВ, или Флешь или HTML то я выбиру html при прочих равных. Т.к. В инет магазинах покупают в основном люди близкие к IT индрустии то часть из них руководствуется тем же.
как мне сделать винапдейт на Debian 5.0 ядро 2.6.26
помнится писали про сайт московского метро, что он мега красив и крут, но я его так и не увидел, ибо нужно было качать силверлайт и в итоге скачав его и перейдя на сайт, браузер завис нафиг и так раза 3 подряд. вот и подумайте оправдались ли усилия заказчиков и разработчиков, которые писали это говно на силверлайте. максимум флэш, сайты должны быть доступны!
Я бы не смог открыть такой каталог, т.к. у меня Linux ((( Лучше бы сделали апплет…
сделал на Silverlight
да ты же упоротый!
да ты же упоротый!
Интернет-магазин не та область, где можно использовать подобный подход.
Обоснуйте такой категоричный вывод
Очевидно же — поисковики не найдут ваш контент.
Мне кажется подобный подход куда лучше для админки данного магазина: возможность быстрее и комфортнее работать оператору.
Мне кажется подобный подход куда лучше для админки данного магазина: возможность быстрее и комфортнее работать оператору.
Очевидно, что можно использовать обычные ссылки, которые будут вести на страницы с товарами. А при клике пользователя, запрашивать json-данные.
К тому же, сейчас все поисковики понимают xml-карты сайтов.
+ Автор использует json данные для поиска по товарам…
К тому же, сейчас все поисковики понимают xml-карты сайтов.
+ Автор использует json данные для поиска по товарам…
Так никто не мешает делать нормальные линки на каждую единицу товара. Если не поддерживается клиентом — то выдаем дубовый html.
Опять же, sitemap никто не отменял.
И экспорт в Маркет — отдельный модуль.
Так что ничего особо критичного не вижу.
Опять же, sitemap никто не отменял.
И экспорт в Маркет — отдельный модуль.
Так что ничего особо критичного не вижу.
Прочитайте внимательно:
>> это не замена… но её (RIA) можно активировать, в случае использования посетителем современного браузера
проверяем с помощью jQuery браузер
if(!$.browser.ie6/7/8 по вкусу){
activateRIA();
}
Поисковик и пользователи ie6 будут получать стандартный вид интернет-магазина.
>> это не замена… но её (RIA) можно активировать, в случае использования посетителем современного браузера
проверяем с помощью jQuery браузер
if(!$.browser.ie6/7/8 по вкусу){
activateRIA();
}
Поисковик и пользователи ie6 будут получать стандартный вид интернет-магазина.
Честно-говоря, мне понравился такой подход. Для крупных магазинов возможно, это не лучший способ оптимизации, но для средних действительно круто.
Честно говоря прочитав, что предложил автор удивился.
Потому что это очевидно. HTML пересылается по запросам с сервера в большинстве магазинов лишь потому, что скорость разработки выше в этом случае.
Короче говоря — статья ни о чем. Ровным счетом.
P.S.
У вас в магазине можно ставить несколько раз галку в одном из фильтров (например цена до 14 000р и от 30 000 — 46 000 и при этом происходит не дизъюнкция результатов а конъюнкция)
Потому что это очевидно. HTML пересылается по запросам с сервера в большинстве магазинов лишь потому, что скорость разработки выше в этом случае.
Короче говоря — статья ни о чем. Ровным счетом.
P.S.
У вас в магазине можно ставить несколько раз галку в одном из фильтров (например цена до 14 000р и от 30 000 — 46 000 и при этом происходит не дизъюнкция результатов а конъюнкция)
> Стоит ли оно того?
Зависит от ассортимента и аудитории. Мои наблюдения и сбор статистики по нескольким магазинам «не для гиков» показали, что люди в большинстве своем просматривают товар, просто перемещаясь по каталогу, оставляя фильтры без внимания. Внедряя подобные вещи, нужно тратиться на неслабое тестирование — клиент-сайд все-таки, и браузерный. Вообщем для большого магазина(в смысле — с большим ассортиментом) вещь не факт что подходящая, а для маленького — рискованная.
Зависит от ассортимента и аудитории. Мои наблюдения и сбор статистики по нескольким магазинам «не для гиков» показали, что люди в большинстве своем просматривают товар, просто перемещаясь по каталогу, оставляя фильтры без внимания. Внедряя подобные вещи, нужно тратиться на неслабое тестирование — клиент-сайд все-таки, и браузерный. Вообщем для большого магазина(в смысле — с большим ассортиментом) вещь не факт что подходящая, а для маленького — рискованная.
Если отмечена цена ноутбука до 15.000, то можно сразу скрыть те параметры фильтра, выбрав которые не будет товара при поиске. Т.е. если стоит галочка на 15.000, было бы удобно, если галочка Объём оперативной памяти — 4 гб была бы неактивна, т.к. таких моделей нет в поиске.
замечание по сортировке — это у вас она быстрая, а вот у некоторых не очень, потому всеравно на операцию ставьте хотя бы cursor: wait
за идею 5+
вопрос о совместимости — на чем и как тестировали? ие?
возможно стоит подгружать картинки товаров в data:uri?
за идею 5+
вопрос о совместимости — на чем и как тестировали? ие?
возможно стоит подгружать картинки товаров в data:uri?
Когда думал, как оптимизировать тяжёлый сайт, тоже задумался об data:uri. Погуглив достаточно и поигравшись понял, что это решение, к сожалению, очень сырое и бажное. Надо делать умное кэширование со стороне сервера и браузера — об этом я позже напишу.
эммм, оно не сырое, просто не работает нормально в ие, кроме магической 9-ки (в 8-ке ограничение в 32 кб на картинку).
умное кеширование — вы про _http://site.com/images.css?v1 или про что-то другое? если да, то схема ничем не отличается от создания того же массива JSON для js, дальше все зависит только от меры оптимизации — можно вообще сжимать сразу после изменения в gzip статические архивы и подсовывать nginx.
ну раз обещали написать — буду ждать
умное кеширование — вы про _http://site.com/images.css?v1 или про что-то другое? если да, то схема ничем не отличается от создания того же массива JSON для js, дальше все зависит только от меры оптимизации — можно вообще сжимать сразу после изменения в gzip статические архивы и подсовывать nginx.
ну раз обещали написать — буду ждать
это если генерировать на стороне сервера base64 картинок, я ещё игрался и со конвертом уже загруженных картинок обычным путём в base64 и сохраниние в кэш, но ограничения и т.п. сводят на нет эти ухишрения.
В целом, если ту же lenta.ru генерировать, учитывая модульность, статику данных и картинку в base64 можно очень разгрузить сервер.
В целом, если ту же lenta.ru генерировать, учитывая модульность, статику данных и картинку в base64 можно очень разгрузить сервер.
Представьте себе, что RIA-вариант того же Хабра, отдаёт всем статический каркас страницы,
а client-side движок на js+jquery фетчет данные о текущих топиках и других «модульных» данных из статических json`ов, которые генерирует динамика сервера единожды.
Хабр может летать. Другой вопрос — это pageview сходит на нет, а этим хвастаются рекламодателям :)
а client-side движок на js+jquery фетчет данные о текущих топиках и других «модульных» данных из статических json`ов, которые генерирует динамика сервера единожды.
Хабр может летать. Другой вопрос — это pageview сходит на нет, а этим хвастаются рекламодателям :)
Единственный минус открытость данных, кто угодно может стянуть полный ассортимент продукции… Является ли это секретом другой вопрос.
Какой недостаток я вижу сразу: если я захочу другу дать ссылку на новинки процессоров, отсортированные по цене, в магазине обычного типа я смогу это сделать:
www.citilink.ru/catalog/parts/cpu/?showOrder=6&available=1&showStatus=2
А в риа? На вашей демке урл не поменяется: sandbox.tematico.ru/citilink/#/cat/parts/cpu/
В общем риа еще пилить и пилить всякие такие мелочи
www.citilink.ru/catalog/parts/cpu/?showOrder=6&available=1&showStatus=2
А в риа? На вашей демке урл не поменяется: sandbox.tematico.ru/citilink/#/cat/parts/cpu/
В общем риа еще пилить и пилить всякие такие мелочи
Конечно пилить. Я же не готовый интернет-магазин делал, а демку концепта. Всё это реализуемо.
Ясно что реализуемо, вопрос в том сколько это займет времени (и денег) на разработку и насколько такой магазин будет прибыльнее обычного (окупятся ли затраты).
Хотя если задача чисто имиджевая для раскрученного магазина то можно и заморочиться
Хотя если задача чисто имиджевая для раскрученного магазина то можно и заморочиться
Да ну, это элементарно решается через location.hash. Посмотрите как меняется урл в яндекс музыке или простоплеере без перезагрузки всей страницы. Сам такое реализовывал — делается на раз-два.
hashchange это всего-лишь возможность использовать хистори.
Сам функционал-то писать придётся на js (посмотрите исходники)
Сам функционал-то писать придётся на js (посмотрите исходники)
таких экспериментов много, но всегда всё упирается в поисковики. И хоть у Google есть поддержка индексирования динамического контента не гуглом единым жив человек.
Прочитайте внимательно:
>> это не замена обычной модели … но её (RIA) можно активировать как «слой», в случае использования посетителем современного браузера
проверяем с помощью jQuery браузер
if(!$.browser.ie6/7/8 по вкусу){
activateRIA();
}
Поисковик и пользователи ie6 будут получать стандартный вид интернет-магазина.
>> это не замена обычной модели … но её (RIA) можно активировать как «слой», в случае использования посетителем современного браузера
проверяем с помощью jQuery браузер
if(!$.browser.ie6/7/8 по вкусу){
activateRIA();
}
Поисковик и пользователи ie6 будут получать стандартный вид интернет-магазина.
Очень интересный «концепт», работает действительно быстро. Но соглашусь с критикой — это двойная разработка интернет-магазина, двойная поддержка, двойной дебаггинг. Возможно, стоит кешировать json-файлы выборок на стороне сервера и каждый раз их отдавать? Для наиболее актуальных выборок можно достичь сравнимой скорости без главных недостатков такого решения…
Всё верно и я это отметил в статье.
Но, если бы мой любимый компьютерный интернет-магазин дал возможность юзать его в RIA-варианте в хроме, опере или фф — было бы просто отлично. Акции магазина сильно бы выросли в моих глазах =)
Но, если бы мой любимый компьютерный интернет-магазин дал возможность юзать его в RIA-варианте в хроме, опере или фф — было бы просто отлично. Акции магазина сильно бы выросли в моих глазах =)
Даже не двойная. Обычно усложнение функционала в 2 раза приводит к усложнению разработки в 4 раза.
Проверил на IE 7 под XP, CPU dualcore 2 герца. На такой машине я предпочел бы сайт без логики на стороне клиента (RIA), тормоза просто недетские, а машина побыстрее среднестатистического нетбука будет.
Поиск в демке ведётся только по маленьким буквам. Если встречается хоть одна заглавная, то пишет, что ничего не найдено.
На всякий случай пишу :)
На всякий случай пишу :)
Ребят, а каких поисковиках идет речь?
Вы забыли правило, что мы сайты делаем для людей, а не для поисковиков.
Нужно просто уметь совмещать технологии.
AJAX тоже по началу все боялись.
Хорошая реализация, хорошей идеи.
Спасибо, автор!
Вы забыли правило, что мы сайты делаем для людей, а не для поисковиков.
Нужно просто уметь совмещать технологии.
AJAX тоже по началу все боялись.
Хорошая реализация, хорошей идеи.
Спасибо, автор!
Концепт интересен, и, в принципе, пользователю можно кидать по onload на загрузку эти файлы, чтобы при поиске они сразу использовались. Но, имхо, это достаточно локальная проблема. Ибо конкретный прирост в скорости (с RIA / без RIA) достаточно мал, чтобы о нем думать. Обычно необходимо первичную оптимизацию провести.
Всё-таки, как ни крути, полный релоад странички — это всегда как минимум запросы к серверу об изменениях всех файлов и ещё рендер скриптов, страницы (мелочь, но всё же) — это не может быть быстрее той же AJAX-подгрузки данных. В приципе.
Думаю это очевидно, что пользователю (а именно о них мы должны думать) субъективно вторая модель будет видеться быстрее.
Думаю это очевидно, что пользователю (а именно о них мы должны думать) субъективно вторая модель будет видеться быстрее.
99 секунд, как ни крути, быстрее, чем 100. Но нужно ли думать о разнице в 1 секунду?
Вы, видимо, не поняли о чём я.
После релоада странички обычным способом, даже если данные (все файлы) не изменились, браузеру надо в этом удостовериться, отправив запросы на сервер if-modified-since
Когда же мы подгружаем данные AJAX-ом, либо берем из кэша (как в демке), каркас странички не перезагружается, а браузер лишь запрашивать об изменении одного файла.
10мс быстрее 700+мс.
Думать о разнице в 690мс стоит.
После релоада странички обычным способом, даже если данные (все файлы) не изменились, браузеру надо в этом удостовериться, отправив запросы на сервер if-modified-since
Когда же мы подгружаем данные AJAX-ом, либо берем из кэша (как в демке), каркас странички не перезагружается, а браузер лишь запрашивать об изменении одного файла.
10мс быстрее 700+мс.
Думать о разнице в 690мс стоит.
Пример искусственный, честно. Обычно при серверной перезагрузке страницы только HTML + счетчик запрашивается + время на рендеринг (которое в общем случае почти такое же выходит). Да, разница есть, 50-100 мс, наверное. Но на фоне непожатых, и необъединенных, и незакэшированных JS-файлов это фигня :)
Браузер при серверной перезагрузке страницы всегда запрашивает актуальность всех подключаемых файлов html/css/js/img/embedded etc.
Посмотрите любым снифером или логи сервера.
Посмотрите любым снифером или логи сервера.
Извиняюсь, но смысла в дальнейшей дискуссии не вижу. Либо мы говорим о разных вещах (и разных поведениях), либо Вы не правы.
То о чём вы писали — это переход на другую страницу уже загруженного сайта, но это явно не «серверная перезагрузка», когда пользователь нажимает обновить.
При переходе на другую страницу запрашивается только хтмл+счётчики, при условии, что у всех объектов загруженных вначале указывается заголовок expires +n.
Если у объекта expires прошедший или такой же как и заголовок date, то даже, перейдя на другую страницу — они-таки проверятся на модификацию запросом if-modified-since.
При переходе на другую страницу запрашивается только хтмл+счётчики, при условии, что у всех объектов загруженных вначале указывается заголовок expires +n.
Если у объекта expires прошедший или такой же как и заголовок date, то даже, перейдя на другую страницу — они-таки проверятся на модификацию запросом if-modified-since.
Но на фоне непожатых, и необъединенных, и незакэшированных JS-файлов это фигня
Действительно, один раз загрузить эти данные — ничего страшного,
по сравнению с
каждый раз ждать ответа сервера на актуальность всех объектов страницы, какой бы она не была оптимизированной, объеденённой и закэшированной.
Если на сервер не отправлять данные о блокировке товара (бронировании), то на момент оформления заказа, нужного товара уже может не оказаться на складе (его купил кто то другой). Естественно для интернет магазинов это не особо критично, а вот при покупке билетов в кино/на самолет/на поезд данная модель не подходит, хотя опять же возможен какой то костыль.
Если в диалоге «мой заказ» удалить все позиции, то 1 «призрачный» товар все же остается.
У меня эта концепция на бумаге уже как 2 года валяется, не слишком знаю JavaScript, хотя это и не очень сложно, думал все знали об этом и не делали из своих предубеждений.
Задумка у меня относилась не только к магазинам, но и социальным сетям.
Задумка у меня относилась не только к магазинам, но и социальным сетям.
А где там собственно RIA?
Знакомьтесь www.ecwid.com/ (отечественная разработка)
В Опере 10.63 «ничего не найдено» при выборе любых галочек в Статусе. В Хроме работает.
Мы в прошлом году подобный проект реализовали «вживую». Поиск частных объявлений: siftia.com
и сразу вам косяк
Проект неактивный, начальство на него забило. Вот, думаю сам добить на node.js, но в порядке частной инициативы. А пока работает, как работает — через пень-колоду. Я вообще удивлен, что через год, без обновления парсеров, он еще что-то (хотя и не полностью) ищет.
Кстати, это был не пиар, я просто хотел продемонстрировать, как мы такое реализовали.
Кстати, это был не пиар, я просто хотел продемонстрировать, как мы такое реализовали.
тест
Этой идеи как минимум лет пятнадцать. Ведь когда вы кликаете на «авторизоваться», то попапы всплывают без перезагрузки.
Вашу демку тоже изобрели несколько лет назад: www.datatables.net/ и даже очень много раз изобрели: www.webdesignbooth.com/15-great-jquery-plugins-for-better-table-manipulation/
Хотя Вы подошли к делу более глобально, предложив спроектировать таким образом весь сайт. К сожалению, только на словах, без демки.
Вашу демку тоже изобрели несколько лет назад: www.datatables.net/ и даже очень много раз изобрели: www.webdesignbooth.com/15-great-jquery-plugins-for-better-table-manipulation/
Хотя Вы подошли к делу более глобально, предложив спроектировать таким образом весь сайт. К сожалению, только на словах, без демки.
Ну здрасьте. А тот же гмейл разве не по такому же принципу? +1 предыдущему оратору — этой идее уже лет 15 =)
Проблема заключается в том, что на скорость работы слишком сильно влияет производительность пк пользователя. Сложность тестирования. Чем больше сайт — тем сложнее его будет делать в геометрической прогрессии и тем медленее он будет работать, независимо от кол-ва серверов у вас. Отлов багов у пользователей превращается в nightmare.
Ну и тд и тп.
Получается что для маленьких магазинов (не бутиков =)) — непозволительная роскошь, а для больших — слишком тяжелые затраты на поддержку.
Проблема заключается в том, что на скорость работы слишком сильно влияет производительность пк пользователя. Сложность тестирования. Чем больше сайт — тем сложнее его будет делать в геометрической прогрессии и тем медленее он будет работать, независимо от кол-ва серверов у вас. Отлов багов у пользователей превращается в nightmare.
Ну и тд и тп.
Получается что для маленьких магазинов (не бутиков =)) — непозволительная роскошь, а для больших — слишком тяжелые затраты на поддержку.
Прежде, чем комментить, надо внимательно вчитываться в текст. И в заголовок. Потом опять. Внимательно. Потом смотреть файрбагом работу того, с чем сравниваете.
Серверный функционал и динамическая подгрузка данных ajax'ом данных от бэкэнда != клиентский функционал и загрузка данных в кэш из статики фронтэнда, без использования бэкэнда.
Да, гмейл работает по другому принципу. И он не интернет-магазин.
После того, как внимательно разберётесь о чём топик, киньте ссылку из веб-архива на интернет-магазин, который работает по такому же концепту.
P.S. где в тексте упоминания о новизне идеи? это лишь применение гибрида новых технологии в сфере интернет-магазинов, не более.
Серверный функционал и динамическая подгрузка данных ajax'ом данных от бэкэнда != клиентский функционал и загрузка данных в кэш из статики фронтэнда, без использования бэкэнда.
Да, гмейл работает по другому принципу. И он не интернет-магазин.
После того, как внимательно разберётесь о чём топик, киньте ссылку из веб-архива на интернет-магазин, который работает по такому же концепту.
P.S. где в тексте упоминания о новизне идеи? это лишь применение гибрида новых технологии в сфере интернет-магазинов, не более.
при просмотре демки, хром просто отваливается
1. Зайдите в оригинальный интернет-магазин, поиграйтесь с сортировкой, фильтрами и т.п. — субъективно запомните скорость от отклика до отображения данных.Сайт грузится ужасно долго, но поиск и фильтры работают превосходно. Несмотря на тормоза, пользоваться удобно, был бы такой магазин в моём городе — пользовался бы им.
2. Сравните скорость в демке интернет-магазина (RIA) (функционал реализован исключительно на стороне клиента с помощью javascript+jquery. Nginx отдаёт только статику. Никаких php, apache, mysql и т.п.).Как программист — повосхищался подходом. Как пользователь — увидел, что автор настолько увлёкся наворотами, что забыл сделать версию без них, в итоге у меня получилось лишь увидеть подобную картинку, повосхищаться затемнением фона выбранного элемента и всё — ни списков, ни фильтров, ни даже товара по категориям мне увидеть не удалось.
Автор забыл важную вещь, что первично для информационного сайта — это дать пользователю доступ к информации — возможно, без плюшек в виде «живого поиска» и без сортировок и работающих фильтров без перезагрузки страницы. А эффекты, скорость и дополнительные фишки — это для магазина дело десятое. Конкуренция на этом рынке достигла уровня, когда можно стать клиентом того магазина, сайт которого удаётся посмотреть без угадывания, какие браузеры имел в виду разработчик, когда реализовывал функционал, доступный исключительно через эти самые браузеры. В завершение приведу примеры правильно спроектированных с этой точки зрения интерфейсов — google, gmail.
Вам не кажется, что автор не «забыл», а просто-напросто не сделал. Вы хотели, чтобы ещё и обычную версию сделали (читайте — полноценный интернет-магазин)? Для демки?
Меня удивляют некоторые комментаторы, которые пишут, даже не вникнув (или не читав?) в текст топика, где отмечено, что это «слой», а не замена. Что это демо и не все реализовано, но реализуемо.
Это всего-лишь демонстрация подхода, возможности сделать RIA-слой для некоторой (продвинутой) аудитории своего интернет-магазина.
А на счёт конкуренции — на западе делают специальные версии сайтов под iPhone и iPad — а это немаленькие деньги на разработку. Они, по вашему, гонятся за «делами десятыми»? — Нет, это ещё один способ привлечь аудиторию, возможно от олдфаг-конкурентов.
Меня удивляют некоторые комментаторы, которые пишут, даже не вникнув (или не читав?) в текст топика, где отмечено, что это «слой», а не замена. Что это демо и не все реализовано, но реализуемо.
Это всего-лишь демонстрация подхода, возможности сделать RIA-слой для некоторой (продвинутой) аудитории своего интернет-магазина.
А на счёт конкуренции — на западе делают специальные версии сайтов под iPhone и iPad — а это немаленькие деньги на разработку. Они, по вашему, гонятся за «делами десятыми»? — Нет, это ещё один способ привлечь аудиторию, возможно от олдфаг-конкурентов.
Кстати, раз уж вы программист, с удовольствием прикручу вашу версию для демки интернет-магазина для noscript'еров, т.е. сервер-сайд решение. Сколько у вас уйдёт личного времени на это?
У меня не noscript, отнюдь. JavaScript и Java включены, но не в этом суть. На сервере есть два типа решения — с использованием server-side-JavaScript и с использованием иного языка программирования. По поводу первого при работе с БД я не знаю абсолютно ничего. По поводу второго — в случае нормализованной базы достаточно сделать что-то вроде (код не проверял):
Для поиска доступных параметров:
Для фильтрации объектов по параметрам:
И передать в шаблон queryset и filters и сформированный аналогичным образом current_filter. Много ли это времени займёт? Нет. А пагинацию добавить? В Paginator() обернуть queryset. А если приделать сортировку по любому полю? Ещё пять строчек. А группировку по любому? Ещё больше. А чтобы плясало и кофе варило? А чтобы и html-шаблоны я писал? А ещё чтоб сервер тоже я админил? В итоге получаем, что на вопрос «сколько у вас уйдёт времени» я ответить вам не смогу, не зная задачи в точности.
Для поиска доступных параметров:
filters = {}
for parameter_name in current_item_type.CAN_BE_FILTERED_ON:
values_list = CurrentItemType.objects.distinct(parameter_name).values_list(parameter_name)
filters[parameter_name] = [lst[0] for lst in values_list]Для фильтрации объектов по параметрам:
queryset = current_item_type.objects.all()
for parameter_name in current_item_type.CAN_BE_FILTERED_ON:
value_exact = request.GET.get(parameter_name)
queryset = queryset.filter(**{parameter_name:value_exact})И передать в шаблон queryset и filters и сформированный аналогичным образом current_filter. Много ли это времени займёт? Нет. А пагинацию добавить? В Paginator() обернуть queryset. А если приделать сортировку по любому полю? Ещё пять строчек. А группировку по любому? Ещё больше. А чтобы плясало и кофе варило? А чтобы и html-шаблоны я писал? А ещё чтоб сервер тоже я админил? В итоге получаем, что на вопрос «сколько у вас уйдёт времени» я ответить вам не смогу, не зная задачи в точности.
Sign up to leave a comment.
Знакомьтесь, Интернет-магазин 2.0 — RIA