Комментарии 25
А где это может пригодится? можете привести пример сценария?
к примеру фотогалерея на аяксе
ссылка вида some.so/gallery#photo12 откроет галерею, а там яваскрипт просмотрит есть ли чтонибудь в параметрах window.location.hash (это как раз все после решетки)
правда были заковырки с эксплорером, при указании window.location.hash = 'something', он не обновлял адресую строку. Когдато я с этим боролся, но не помню на чем остановился.
Плюс для полноценного использования эти переходы должны запоминаться в history. В эксплорере опять же с этим были проблемы, нужно было создавать iframe и в нем реально чтото листать. В лисе все было без заковырок.
ссылка вида some.so/gallery#photo12 откроет галерею, а там яваскрипт просмотрит есть ли чтонибудь в параметрах window.location.hash (это как раз все после решетки)
правда были заковырки с эксплорером, при указании window.location.hash = 'something', он не обновлял адресую строку. Когдато я с этим боролся, но не помню на чем остановился.
Плюс для полноценного использования эти переходы должны запоминаться в history. В эксплорере опять же с этим были проблемы, нужно было создавать iframe и в нем реально чтото листать. В лисе все было без заковырок.
за такое на проекте у нас бьют по рукам. и правильно.
не понял :(
это для того, чтобы не перегружать всю страницу целиком, а изменить только фотографию?
это для того, чтобы не перегружать всю страницу целиком, а изменить только фотографию?
именно
основная проблема этого подхода в том что поисковики не проиндексируют этот контент никак
а сам топик мутный совершенно
основная проблема этого подхода в том что поисковики не проиндексируют этот контент никак
а сам топик мутный совершенно
смутно начинаю представлять: в линках "к следующей фотографии" и "к предыдущей" будет стоять вот такая ссылка, как Вы описали в статье, к ссылке привязан обработчик события (или обработчик нужно привязывать к событию onload() всей страницы? уточните пожалуйста) который асинхронно подгружает фотку и описание.
если обычный браузер щелкает по ссылкам, то с сервера грузится только описание и фотография, если же поисковик, то грузится вся страница с описанием и фотографией.
правильно я понимаю?
если обычный браузер щелкает по ссылкам, то с сервера грузится только описание и фотография, если же поисковик, то грузится вся страница с описанием и фотографией.
правильно я понимаю?
разберемся последовательно:
- статью писал не я
- событие onload не сработает так как не было перезагрузки страницы
еcли уж сильно хочется такое событие сделать то можно переодически проверять не изменился ли window.location.hash
- поисковики вроде яваскрипт пока не исполняют и то что они увидят по адресу http://sss.aa/ddd ничем не будет отличатся от http://sss.aa/ddd#asda
Подобную систему в работе я видел в гугловских фотогалереях picasaweb.google.com
Им индексация и не тарахтела )))
- статью писал не я
- событие onload не сработает так как не было перезагрузки страницы
еcли уж сильно хочется такое событие сделать то можно переодически проверять не изменился ли window.location.hash
- поисковики вроде яваскрипт пока не исполняют и то что они увидят по адресу http://sss.aa/ddd ничем не будет отличатся от http://sss.aa/ddd#asda
Подобную систему в работе я видел в гугловских фотогалереях picasaweb.google.com
Им индексация и не тарахтела )))
я почему-то думал, что # - это якорь
Я и сейчас так думаю. А параметры в яваскрипт сервер должен передавать через тег SCRIPT и не как иначе.
поддерживаю на 100%. автор, вероятно, не знает, что такое копаться в коде, который был написал пол-года назад.
Если застандартизировать jR, то никто путаться не будет, а копаться в коде, который был написан полгода назад всегда будет сложно.
объясните мне следующее. как после перезагрузки страницы перепрыгнуть к определенному элементу, если использовать ваш, так называемый, jR?
у нас на проекте это реально используется. я на собственном опыте знаю, чем все такое заканчивается. пишется "свой собственный под-фреймворк", который выбрасывается в следующей фазе, так как он становится настоолько неуправляемым, что поддерживать его становится себе дороже.
в Вашем случае необходимо будет различать, это реально якорь, или просто параметры для js, появятся общие функции, которые будут каждый раз это все дело парсать и все это превратиться в неуправляемый флейм на страницах и в коде. _imho_, гораздо дешевле придерживаться стандартов (в данном случае, передавать параметры через GET, POST, куки), чем изобретать велосипед и прикручиваить к нему костыли, чтобы поддержать стандартную функциональность.
у нас на проекте это реально используется. я на собственном опыте знаю, чем все такое заканчивается. пишется "свой собственный под-фреймворк", который выбрасывается в следующей фазе, так как он становится настоолько неуправляемым, что поддерживать его становится себе дороже.
в Вашем случае необходимо будет различать, это реально якорь, или просто параметры для js, появятся общие функции, которые будут каждый раз это все дело парсать и все это превратиться в неуправляемый флейм на страницах и в коде. _imho_, гораздо дешевле придерживаться стандартов (в данном случае, передавать параметры через GET, POST, куки), чем изобретать велосипед и прикручиваить к нему костыли, чтобы поддержать стандартную функциональность.
При всем уважении к вашему опыту, всё таки считаю, что технология имеет право на жизнь.
Отделять обычные якори от jR предполагается (в большом тексте это написано) по простому правилу: есть двоеточие после символа решотки, — значит, — jR, нету, — значит обычный якорь. Всё это решаемо.
Ещё раз повторю: это не «стандартная функциональность». И я не вижу сейчас способов сделать что-то подобное по-другому.
Отделять обычные якори от jR предполагается (в большом тексте это написано) по простому правилу: есть двоеточие после символа решотки, — значит, — jR, нету, — значит обычный якорь. Всё это решаемо.
Ещё раз повторю: это не «стандартная функциональность». И я не вижу сейчас способов сделать что-то подобное по-другому.
Якорь. Вы имеете конструкцию
Да так было в HTML, но с приходом XML/XHTML/RDF его можно и нужно использовать для других целей. Т.е. теперь это, — указатель на какую-то часть, допустим, XML документа.
Конечно, использования '#' для передачи параметров JavaScript не описано стандартом, но и не особо запрещено, если честно.
Всё что там сказано, — это то, что часть после решотки должна удовлетворять [a-zA-Z][a-zA-Z_.:-]*
Да так было в HTML, но с приходом XML/XHTML/RDF его можно и нужно использовать для других целей. Т.е. теперь это, — указатель на какую-то часть, допустим, XML документа.
Конечно, использования '#' для передачи параметров JavaScript не описано стандартом, но и не особо запрещено, если честно.
Всё что там сказано, — это то, что часть после решотки должна удовлетворять [a-zA-Z][a-zA-Z_.:-]*
Зачем необходимо загрязнять URL, если можно, к примеру, свободно манипулировать глобальными javascript-переменными или скрытыми полями.
Не совсем понятно применение данной методики?
Можно пример?
Не совсем понятно применение данной методики?
Можно пример?
В ряде случаев (в качестве примитивного примера - поиск) загрязнение URL может быть полезным - человек может скопировать URL из адресной строки и передать его кому-либо, вместо объяснения "набери в строке поиска такую-то фразу и выставь такие-то параметры поиска (при использовании расширенного поиска)".
Но. # - это все же якорь и не стоит использовать его иначе без необходимости, хотя бы из уважения к стандартам и чтобы не путать пользователей, которые могут воспринять этот символ буквально - как якорь.
Переменные при обновлении страницы через AJAX можно хранить как угодно - ничего с ними не сделается. Чтобы передавались в JS при переходе по ссылке с внешнего ресурса - обычные GET-запросы (пусть хоть сервером обрабатываются, хоть JS - зависит от задачи).
Остается одна проблема - продемонстрировать переход к новой информации в строке адреса для пользователя. Наверняка есть какое-то решение без использования символа "#".
Но. # - это все же якорь и не стоит использовать его иначе без необходимости, хотя бы из уважения к стандартам и чтобы не путать пользователей, которые могут воспринять этот символ буквально - как якорь.
Переменные при обновлении страницы через AJAX можно хранить как угодно - ничего с ними не сделается. Чтобы передавались в JS при переходе по ссылке с внешнего ресурса - обычные GET-запросы (пусть хоть сервером обрабатываются, хоть JS - зависит от задачи).
Остается одна проблема - продемонстрировать переход к новой информации в строке адреса для пользователя. Наверняка есть какое-то решение без использования символа "#".
Остается одна проблема - продемонстрировать переход к новой информации в строке адреса для пользователя. Наверняка есть какое-то решение без использования символа "#".
К сожалению, нет. Если вы меняете url, то запрос будет отправляться на сервер если точно такого-же запроса небыло раньше. Единственное исключение, — это использовать символ '#'. Если бы в W3C сделали подобные конструкции в URL, то я бы и не предлагал использовать '#'.
К сожалению, нет. Если вы меняете url, то запрос будет отправляться на сервер если точно такого-же запроса небыло раньше. Единственное исключение, — это использовать символ '#'. Если бы в W3C сделали подобные конструкции в URL, то я бы и не предлагал использовать '#'.
НЛО прилетело и опубликовало эту надпись здесь
Передача через GET кирилицы, — это не большее загрязнение URL, чем использование jR. Одинако это грязно.
HTTP GET и jR были созданы для разных потребностей, их нельзя сравнивать, просто лучше выписать, — какие характеристики имеет один способ, какие другой.
Если коротко, — то при использовании jR не происходит обращение к серверу (если страница в кеше), а GET удобно использовать для seo-шников совместно с mod_rewrite, допустим (чтоб красиво было).
Каждый метод хорош, и имеет свои характерные отличия от других.
HTTP GET и jR были созданы для разных потребностей, их нельзя сравнивать, просто лучше выписать, — какие характеристики имеет один способ, какие другой.
Если коротко, — то при использовании jR не происходит обращение к серверу (если страница в кеше), а GET удобно использовать для seo-шников совместно с mod_rewrite, допустим (чтоб красиво было).
Каждый метод хорош, и имеет свои характерные отличия от других.
и вот ведь что любопытно... флешеры подобную технику уже несколько лет как используют. и уже наспотыкались и обошли кучу граблей, даже тех о которых комментаторы пока не догадываются :)
попробуйте подсмотреть у них
попробуйте подсмотреть у них
Огромное спасибо за подсказку.
Здесь, кстати, и кроется ответ на то, о чем все спорят выше.
На сегодняшний день Rich Internet Applications (RIA) и AJAX, — две технологии, которые могут быть использованы для написания полноценных web applications.
Первая, — flash based, вторая, — JavaScript based.
При достижении определенного уровня и объема приложения (сервиса, сайта, называйте как хотите) появилось желание передавать параметры непосредственно этому приложению (которое физически находится в кеше браузера), — без запросов к серверу.
А раз появляется желание, то мы его и удовлетворили, для этого заюзали что могли, — символ решетки.
Думаю, кстати, что если ТБЛ написать, то он возможно согласится, что в URL просто тупо надо добавить возможность таких запросов, только уже не полулегальным через решетку а цивилизованным, — через специальные конструкции, — возможно какой-то другой символ.
На сегодняшний день Rich Internet Applications (RIA) и AJAX, — две технологии, которые могут быть использованы для написания полноценных web applications.
Первая, — flash based, вторая, — JavaScript based.
При достижении определенного уровня и объема приложения (сервиса, сайта, называйте как хотите) появилось желание передавать параметры непосредственно этому приложению (которое физически находится в кеше браузера), — без запросов к серверу.
А раз появляется желание, то мы его и удовлетворили, для этого заюзали что могли, — символ решетки.
Думаю, кстати, что если ТБЛ написать, то он возможно согласится, что в URL просто тупо надо добавить возможность таких запросов, только уже не полулегальным через решетку а цивилизованным, — через специальные конструкции, — возможно какой-то другой символ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Запросы к JavaScript