Думаю, автор имел в виду не «свободные», а «бесплатные» лицензии. Программа остается проприетарной, но распространяется бесплатно. Пример — virtualbox (который не OSE). Пользуй на здоровье, но исходники не получишь.
При желании можно пакеты для любого ip перенаправить на локальный хост (дело пяти минут). Так что такая проверка бессмысленна. Вот если общение организовать по SSL с проверкой сертификата сервера — вот это уже хуже. Но тоже обходится.
Мне кажется, что автор прав. Причем тут спецэффекты? На все действительно понравившиеся фильмы из скачанных мною ходил в кинотеатр (если такая техническая возможность была). Просто в кинотеатре смотрятся они лучше, чем дома.
И далеко не все фильмы из просмотренных в кинотеатре я хотел бы скачать (а честно если, то в большинстве случаев было бы неплохо деньги возвращать за впустую потраченное время).
0. Ну, «15 минут» — больше фигурально сказано. Но в любом случае трудозатраты там относительно небольшие.
1. Утяжеление, еще раз, небольшое. Если вообще ajax используется.
2. Что мешает сервером сразу тоже рендерить результат?
3.
а) История в IE — актуально для IE6(7?). В этом случае пишется библиотечка, или берется готовая. Она грузится один раз для всего сайта и оседает в кешах браузера. А восьмой IE даже onhashchange понимает, и для него огород городить не надо.
б) Обработка ошибок — вы ведь их обрабатываете на сервере уже? Еще раз, задача — получить готовый html с результатами, и его воткнуть на место текущих результатов. Или вы в JSON'е данные принимаете, и потом разметку в js генерируете?
в) обработка скриптов — миллион лет назад уже в jQuery все сделано. Не надо про его размер говорить, он наверняка у всех в кешах есть (если с гугла тащить), а если нет — то требуется один раз для всего сайта загрузить.
г) про агрессивное кеширование не совсем понял — уточните, в чем там проблемы (которые есть при использовании AJAX'а, и нет в обычной реализации)?
4. Поскольку разобрались со вторым пунктом, то ускорение таки будет?
Кроме генерации есть еще время запроса/ответа, есть время рендеринга всей страницы (небольшое, но есть), есть время перемотки к результатам поиска. Да и визуально ajax-переход выглядит быстрее.
В общем, вопрос тут, скорее, в правильной реализации. Тогда это будет быстрее. А кода все равно не так уж много (если, конечно, jQuery самому не изобретать).
Для лечения описанных болезней давно уже придумали множество способов, один из которых — изменять location.hash и отслеживать его изменение, тогда и история сохраняется, и букмарки работают, и обновление страницы приводит ее к тому же состоянию.
1. Взять работающий поиск
2. выдрать результат выдачи в отдельный серверный скрипт/шаблон
3. взять пример выше, воткнуть в коллбэк $('#results').replaceWith(response)
4. либо в вызове ajaxForm, либо в submit указать url нового скрипта =)
5. ???
6. PROFIT!!!
Такая штука даже снизит нагрузку (как минимум, страница целиком лишний раз не генерится), а делается за 15 минут. Скриптов 10 строк добавилось.
Пользователям без JS можно, например, заполнять форму на сервере ;-)
А способ применения… ИМХО, самый очевидный (и для чего оно нужно было мне) — для навигации по результатам ajax-поиска:
— форма сериализуется, результат пишется в window.location.hash
— при загрузке страницы данные из location.hash десериализуются, а форма отправляется на сервер.
Тогда остается поиск без перезагрузки страницы, и по прежнему можно скопировать ссылку на результат выдачи, и отправить ее знакомому, например.
В случае jQuery Form Plugin выглядит примерно так:
Гм, да. Неотмеченные чекбоксы отсутствуют в строке, форму надо чистить перед десериализацией. У себя я использую jQuery.Form Plugin, метод clearForm(). Но могу подобный дописать сюда. Надо?
Как по мне, так пиратки и торренты (в плане фильмов) в сто раз удобней любого(!) лицензионного магазина.
Минимум тем, что там на одно движение меньше — не надо напрягаться с вводом наличных в системы электронных платежей. Поясню:
У меня есть только наличка, постоянно держать какой-то запас электронных денег я не хочу (их фиг выведешь в случае чего, да и на комиссию туда-сюда не хочется тратиться, а регулярных затрат в электронных деньгах у меня нет). А вот приспичило мне фильм глянуть — нашел его в одном из десяти магазинов (хорошо, если вообще нашел, какой-нибудь не особо популярный 1984 года может и не найтись), дальше-то что? А дальше вот:
1. Надо зарегистрироваться (и это когда есть OpenID!) и залогиниться
3. Надо найти информацию об оплате, выяснить, как можно пополнить счет
4. Оказались, например, веб-мани, стоимость фильма, например, 1WMZ.
5. Надо ввести наличку. Ввести быстрее всего вроде через какой-нибудь QIWI. Ввод только в рублях. Посчитал — полтинника хватит (комиссии в WebMoney — это вообще отдельная тема, фиг поймешь, сколько тебе точно денег надо ввести) — собрался, дополз до терминала, пополнил.
6. Подождал 2 часа (задержка зачисления на WebMoney)
7. Поставил заявку на обмен
8. Дождался, когда обменяют
9. Заплатил.
10. Скачал.
С торрентами, даже если требуется регистрация на трекере, уложимся максимум в три(!) шага, не вставая при этом с кресла и практически моментально — зарегистрировался, слил торрент-клиент, слил фильм. И мне не жалко полтинника за фильм, мне надо, чтоб я наличкой в любой момент мог расплатиться, никуда не дергаясь. В крайнем случае, кредитная система — выставили счет за месяц, я его оплатил.
И далеко не все фильмы из просмотренных в кинотеатре я хотел бы скачать (а честно если, то в большинстве случаев было бы неплохо деньги возвращать за впустую потраченное время).
1. Утяжеление, еще раз, небольшое. Если вообще ajax используется.
2. Что мешает сервером сразу тоже рендерить результат?
3.
а) История в IE — актуально для IE6(7?). В этом случае пишется библиотечка, или берется готовая. Она грузится один раз для всего сайта и оседает в кешах браузера. А восьмой IE даже onhashchange понимает, и для него огород городить не надо.
б) Обработка ошибок — вы ведь их обрабатываете на сервере уже? Еще раз, задача — получить готовый html с результатами, и его воткнуть на место текущих результатов. Или вы в JSON'е данные принимаете, и потом разметку в js генерируете?
в) обработка скриптов — миллион лет назад уже в jQuery все сделано. Не надо про его размер говорить, он наверняка у всех в кешах есть (если с гугла тащить), а если нет — то требуется один раз для всего сайта загрузить.
г) про агрессивное кеширование не совсем понял — уточните, в чем там проблемы (которые есть при использовании AJAX'а, и нет в обычной реализации)?
4. Поскольку разобрались со вторым пунктом, то ускорение таки будет?
Кроме генерации есть еще время запроса/ответа, есть время рендеринга всей страницы (небольшое, но есть), есть время перемотки к результатам поиска. Да и визуально ajax-переход выглядит быстрее.
В общем, вопрос тут, скорее, в правильной реализации. Тогда это будет быстрее. А кода все равно не так уж много (если, конечно, jQuery самому не изобретать).
msdn.microsoft.com/en-us/library/system.xml.serialization.xmlserializer_members.aspx
1. Взять работающий поиск
2. выдрать результат выдачи в отдельный серверный скрипт/шаблон
3. взять пример выше, воткнуть в коллбэк $('#results').replaceWith(response)
4. либо в вызове ajaxForm, либо в submit указать url нового скрипта =)
5. ???
6. PROFIT!!!
Такая штука даже снизит нагрузку (как минимум, страница целиком лишний раз не генерится), а делается за 15 минут. Скриптов 10 строк добавилось.
А способ применения… ИМХО, самый очевидный (и для чего оно нужно было мне) — для навигации по результатам ajax-поиска:
— форма сериализуется, результат пишется в window.location.hash
— при загрузке страницы данные из location.hash десериализуются, а форма отправляется на сервер.
Тогда остается поиск без перезагрузки страницы, и по прежнему можно скопировать ссылку на результат выдачи, и отправить ее знакомому, например.
В случае jQuery Form Plugin выглядит примерно так:
jQuery.Form Plugin, метод clearForm(). Но могу подобный дописать сюда. Надо?
mvasiliev.ru/js/jquery.urlencode.js
У элементов с множественным выбором опций (чекбоксы, мультиселекты) нужно группировать значения в массив.
Минимум тем, что там на одно движение меньше — не надо напрягаться с вводом наличных в системы электронных платежей. Поясню:
У меня есть только наличка, постоянно держать какой-то запас электронных денег я не хочу (их фиг выведешь в случае чего, да и на комиссию туда-сюда не хочется тратиться, а регулярных затрат в электронных деньгах у меня нет). А вот приспичило мне фильм глянуть — нашел его в одном из десяти магазинов (хорошо, если вообще нашел, какой-нибудь не особо популярный 1984 года может и не найтись), дальше-то что? А дальше вот:
1. Надо зарегистрироваться (и это когда есть OpenID!) и залогиниться
3. Надо найти информацию об оплате, выяснить, как можно пополнить счет
4. Оказались, например, веб-мани, стоимость фильма, например, 1WMZ.
5. Надо ввести наличку. Ввести быстрее всего вроде через какой-нибудь QIWI. Ввод только в рублях. Посчитал — полтинника хватит (комиссии в WebMoney — это вообще отдельная тема, фиг поймешь, сколько тебе точно денег надо ввести) — собрался, дополз до терминала, пополнил.
6. Подождал 2 часа (задержка зачисления на WebMoney)
7. Поставил заявку на обмен
8. Дождался, когда обменяют
9. Заплатил.
10. Скачал.
С торрентами, даже если требуется регистрация на трекере, уложимся максимум в три(!) шага, не вставая при этом с кресла и практически моментально — зарегистрировался, слил торрент-клиент, слил фильм. И мне не жалко полтинника за фильм, мне надо, чтоб я наличкой в любой момент мог расплатиться, никуда не дергаясь. В крайнем случае, кредитная система — выставили счет за месяц, я его оплатил.