Pull to refresh

Comments 72

Интересно, но я так понимаю что кроме красоты GET запроса это ничего не дает?
И я на вскидку не нашел экранирование разделителей. Что будет если в имени элемента будет подчеркивание? :)

Не совсем понимаю нафига нужна реализвация на JS. Для формирования нужной строки запроса проще сразу нужным образом назвать имена формы. Тут скорее надо серверный класс для формирования обьекта(ов) из запроса и проименовывания полей формы. А для передачи данных в AJAX лучше JSON пока ничего нет имхо.
> Интересно, но я так понимаю что кроме красоты GET запроса это ничего не дает?
это как бы унифицированный формат, позволяющий использовать один и тот же парсер для получения данных из разных источников (псевдостатика, гет или пост форма (если не мультипартом посылается конечно), консоль )

> И я на вскидку не нашел экранирование разделителей. Что будет если в имени элемента будет подчеркивание? :)
обычное кодирование через проценты + дополнительно подчёркивание кодируется. смотри функции encode и decode

> Не совсем понимаю нафига нужна реализвация на JS.
чтобы было с чем сравнивать при написании библиотек на других языках. а вообще, js-библиотека полезна для всяких аяксовых сайтов, для хранения параметров в урле без перезагрузки страницы.

> А для передачи данных в AJAX лучше JSON пока ничего нет имхо.
json в урле смотрится слишком дибильно %-)
tenshi : > А для передачи данных в AJAX лучше JSON пока ничего нет имхо.
json в урле смотрится слишком дибильно %-)
А кто ж видит урл AJAX запроса? Даже если представить что приспичило данные в GET передать.
да хотябы разработчик. что за дурная привычка получать данные аяксом через пост запрос?
И чем же она дурная?
например тем, что пост запросы не кэшируются. или тем, что нельзя повторить запрос просто щёлкнув по ссылке. или тем, что нет достаточно простого способа подкорректировать значение руками.
Это все отмазки. И кэш работает отлично и запросы можно повторить и сымитировать. В крайнем случае можно на сервере обрабатывать оба запроса.
и каким таким волшебным образом кэш работает без ключей? х))) или он их из поста вытягивает?

я не говорил, что это невозможно. но мне не нужен этот геморрой.
А кто мешает ключ положить в etag или в get, если запрос не уникален для пользователя?
прочие данные зачем туда же пихать?

А насчет геморроя — существуют post формы и с ними тоже надо как-то работать. Так что приходиться один раз пройти через все это что бы потом не видеть разницы между get и post ajax запросами.
сами данные и являются ключём.

===
habrahabr.ru/ajax/blogs/getinfo/

HTTP Information
Request Method:POST
Status Code:200 OK
Request Headers
Content-type:application/x-www-form-urlencoded
Origin:http://habrahabr.ru
Referer:http://habrahabr.ru/blogs/webstandards/92300/
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1064 Safari/532.5

Form Data
kind:administration
blog_id:339
===

идиотизм
ты уже прошёл? и как успехи?
:) я же вроде ясно выразился еще в первом камменте.
для меня озвученные причины не являются основанием пихать все в строку запроса.
Hiqus — непонятная штука…
А вот за способ написания тестов спасибо
эти типа json только по другому =_="
ЧПУ в явном виде он не дает, да и в современный фреймворках пишут свои правила разбора url, так что непонятно, в чем преимущество перед обычным запихиванием параметров в get.
он даёт человекопонятное представление иерархических структур в одномерном пространстве ;-)

ну это уже каждый решает сам какой парсер использовать. как правило во фреймворках идёт наколеночный разбор запроса с помощью регекспов, создавая кашевидный набор правил…
Зачем клиентам (не программистам) нужно понятное представление структур в урлах?
Навигация осуществляется посредством кликов по активным контролам сайта, а какой будет урл — никому не интересно.

Не так?
в сети достаточно полно достаточно сообразительных непрограммистов, которые могут применять это с пользой для себя. делать сайты исключительно для хомячков — не интересно и не даёт морального удовлетворения. мне нравятся красивые и понятные урлы, которые я могу набрать по памяти, а не искать нужную ссылочку, пробираясь через груду активных контролов.
напиши последний упл с параметрами, который ты набирал по памяти
как я понял — ты против GET параметров, а не против вообще любых структур в урле
неужели ты предлагаешь удобный и понятный blogs/webstandards заменить на пресловутый хикус?

ещё раз — напиши последний урл, который без хикуса хуже, чем с хикусом.
нет, совсем не против. blogs/webstandards замечательно парсится как хикус. я же в примерах даже написал…
не вижу этого в тестах
ну добавь сам, если тебе пренепременно эта строчка нужна в тестах
>> Данный формат уже используется такими монстрами как Яндекс, Гугл
Где?

>> Исключение составляют PHP-сайты, для которых традиционно используется свой, не слишком наглядный формат
это не свой формат пхп, это стандарт кодирования данных, описанный RFC2396, если не ошибаюсь
в урлах

речь про линейную запись иерархических структур, а не экранирования специальных символов
тогда непонятно с какого бока здесь гугл и яндекс. эти стандартом пользуются вообще все, потому что он стандарт.
а разве не очевидно? х) чтобы примазаться к великим
Я тоже не понял про пример с Яндексом и Гуглом. Если у них в запросе используются ключи с подчеркиванием, это еще ничего не значит.
это значит что их урлы соответствуют спецификации hiqus и могут быть правильно обработаны его парсером
вот только кем эти параметры будут сгенерированы? будучи отправлены формой с GET — браузер сам формирует правильную строку запроса.
если выключить на клиенте JS, то каким волшебным образом получится работать с хикусом?
хикус — это формат. совместимый в том числе и с хтмл-формами. причём тут вообще js?
ок.
/>
/>


что получится после сабмита? как оно превратится в хикус?
парсер съел )))

form
input type=«text» name=«param»
input type=«submit»
любой «application/x-www-form-urlencoded» является частным случаем хикуса
на примере урла из яндекса — чтобы писать YaDate( request.from ) и YaDate( request.to ), а не YaDate( request.from_year, request.from_month, request.from_day ) и тп
другими словами — вместо явного интерфейса — валить в функцию YaDate вообще всё, что пришло от юзверя в from_*?

from_omg=foobar&from_omgomg=baz
Зачем явные интерфейсы превращать в неявные? Кому от этого станет легче жить?
всем. именованные параметры рулят.
не рулят. итого — объективных причин нет?
это объективная причина.
Это субъективная причина. Своё субъективное мнение, расходящееся с твоим, я изложил комментом ниже
ну да, передача параметров массивом, а не хэш-таблицей — куда лучше, конечно х)
Объективно с помощью терминов теории программирования можешь назвать причины, чем лучше?
да хотябы тем, что не надо считать параметры у декларации и у вызова, чтобы понять что за циферка передана 5 параметром после двух null-ов
а откуда узнать, что передавать аргументами? в случае явных интерфейсов — достаточно посмотреть на список аргументов.
документировать? смотреть сорсы?
а как ты узнаёшь типы или требуемые интерфейсы параметров?
Типы очевидно следуют из корректно подобранных имён, а сам прототип — мне подсказывает автокомплитом Aptana.
ps: неужели и этот бесполезный комментарий неизвестный кто-то тоже плюсанёт??
ты предлагаешь венгерскую нотацию? для каждого класса по своему префиксу? х)

что, прям пишет какой параметр как называется в декларации, когда ты елозишь по коду мышкой?
не венгерскую, конечно. у меня имена и без венгров вполне однозначные.
ну по ctrl+space подсказывает. по наведению не уверен, вроде нет.
что-то типа new MapVector( aMapPoint_From, aMapPoint_To, aMapStyleBrush )?

м… ясно, ещё один любитель write-only кода…
Я же сказал — не венгерскую. Хотя ты всю дискуссию не читал, что пишут другие — глупо было ожидать этого сейчас.

Для себя все сделали выводы — я любитель write-only кода, а ты — гениальный изобретатель мертворожденного протокола.

Спасибо за дискуссию.
Явный интерфейс самодокументируемый. По его прототипу можно понять, что и как передавать. Неявные интерфейсы — нужно описывать отдельно и специально.
вам шашечки или ехать?
Мы ездим и так без проблем. А вот ты придумал стандарт, который придётся дополнительно поддерживать и портить красивые интерфейсы.
о, да, суперский интерфейс YaDate( 2010, 1, 1, 1, 1, 1 )
Это не интерфейс. Это вызов. Я говорил о прототипе метода.
а давно у нас в яваскрипте у прототипа метода появилась типизация параметров?
UFO landed and left these words here
UFO landed and left these words here
> Данный формат уже используется такими монстрами как Яндекс (http://yandex.ru/yandsearch?date=within&text=hiqus&from_day=28&from_month=4&from_year=2009), Гугл (http://www.google.ru/search?as_q=hiqus&hl=ru&num=10&as_qdr=all) и многими другими, кому требуется передавать иерархические данные в строке запроса.

Ой ли! По мне так у них обычный способ кодирования данных, не надо придумывать.

Из недостатков: по моему, многовато разделителей, неуклюже получается. И командная строка непонятно зачем тут. Во-вторых, громоздкий яваскрипт (хотя, если не парсить этот hiqus на клиенте, он и не нужен), да еще небось и тормозной, там на каждый чих объекты заново создаются.
в том его и прелесть, что он уже интуитивно используется многими. hiqus — это перевод де-факто в де-юре.

никто на заставляет использовать все разделители

затем, что наш скрипт может быть вызван и из неё

это не так страшно, как кажется
в том его и прелесть, что он уже интуитивно используется многими. hiqus — это перевод де-факто в де-юре.

На вашем тесте
( Hiqus( 'a=1=2/b=2=3' ).get('b',2), '3' )
выдается ошибку
Хотелось бы понять — ошибка в тесте или в функции Hiqus?
ого, кто-то всё-таки запустил %-)
в тесте. правильный тест такой:
( Hiqus( 'a=1=2/b=2=3' ).get('b','0'), '3' )
Only those users with full accounts are able to leave comments. Log in, please.