Information

Founded
Location
Россия
Website
www.luxoft.com
Employees
5,001–10,000 employees
Registered
Pull to refresh
Comments 37
Как интересно! Это бы к Друпалу ещё как-то прикрутить…
Статья про друпал буде в ближайшем времени, правда, не уверен на эту ли тему
… и к MODX-у. Вот насчёт MODX-а вообще было-бы интересно, вообще лучший способ работы с ним и AJAX-ом.
К Друпалу это прикручивается легко. В простейшем случае, например, достаточно в page.tpl.php добавить проверку вроде
if (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && ('xmlhttprequest' == strtolower($_SERVER['HTTP_X_REQUESTED_WITH']))) {
    // возвращаем JSON
    drupal_set_header('Content-Type: application/json; charset=UTF-8');
    $r['title'] = $head_title;
    $r['content'] = $content;
    print json_encode($r);
} else {
    // нормальный page.tpl.php
}


А если к этому ещё добавить кэширование на фронтенде, например, использовать fastcgi_cache в nginx, то ajax-навигация совсем летает. Несколько месяцев назад как раз делал такую связку: nginx + php-fpm + Drupal и ajax-навигация поверх этого с fallback до обычной. Правда, кэширование контента страниц целиком корректно работает только для анонимных посетителей, и вообще, имеет некоторые ограничения и не всегда уместно.
ну да, это у друпала есть такая особенность…
Различать на сервере можно как угодно, но использовать одновременно две версии страницы с одним урлом плохо.
ajax-версия попадает в кэш браузера и если потом не по ajax-переходу открыть тот же урл (например, закрыть вкладку и отменить закрытие) — страница возьмется из кэша, то есть json или кусок html вывалится прямо в пустую страницу.
Когда я такое реализовывал, в FF все было ок, а в хроме ломалось, пришлось таки дописывать ajax=1, хоть сервер этот параметр и игнорировал.
Можно вырубить кэширование совсем через Cache-Control: no-store, но обычно это избыточно агрессивный запрет, он ломает быстрое восстановление сессий браузера и переходы по обычной истории.
Теоретически, в HTTP для такого придумали заголовок Vary, на практике, увы, он нигде нормально не поддерживается.
если пользователь пользуется проксёй то данный заголовок ($_SERVER['HTTP_X_REQUESTED_WITH']) теряется, так что использование дополнительного параметра оправдано.
С одной стороны фоновая подзагрузка увеличивает скорость, но с другой это делается независимо от желания пользователя.

Если человек заходит с телефона(мобильный интернет) и у него вместо одной вкладки подгружаются все!, то он не сильно будет рад остатку своих бесплатных мб на день…
На телефонах тачскрин, там вряд ли можно невзначай провести курсором мимо ссылки. Но у пользователей компьютеров с мобильным интернетом такая проблема возникнуть может.
Да, но в статье еще написано про автоматическую подзагрузку табов, при готовности текущего таба, которая точно произойдет на телефоне.
Не особо спасет.

В маленьких городах до сих пор есть проблемы с трафиком. Например, стоит пакет на 1.2гб в месяц. И это на стационарном ПК, А если в этих табах решили выложить фотоподборку со 100+ фотографий?

И все это происходит пока пользователь ничего даже не подозревает!

Конечно, такое уже редкость, но все же не нужно забывать о таких вещах. Данный подход к построению сайта намного лучше и быстрее в работе, но не для всех это +.
Сайт с такими динамическмими блоками будет полноценно индексироваться поисковиками?
Переделаем все ссылки подобным образом:
<a onclick="go('/someurl', null, event); return false;" href="/someurl">Some link</a>

Не вижу ни каких сложностей. Сайт будет работать даже у тех, у кого отключена поддержка JavaScript
Только надо, конечно, не ссылки менять, а на jQuery навесить $('a').live('click') — можно отдельный class=«ajaxable» навесить на них, а можно и какую-то другую эвристику. Onclick везде вручную прописывать — плохой вариант.
Можно и live(). Я просто процитировал код автора статьи.
В любом случае на индексацию это никак не повлияет.
Зачем на меню вешать .live() если оно не должно возвращаться сервером при ajax запросе?

Хватит и простого $(menu.elem).click(...)
Вместо
onclick="go(....)"
я лично использовал навешивание onclick обработки по классу и .live() — код чище :)
Если все же в onclick, то лучше onclick="return go(...)", а в function go добавлить return false;
а конкретнее с помощью jQuery
$('a').live('click', function(e){ e.preventDefault(); go($(this).attr('href',...); })
fizzer.ph — тут можно глянуть мой вариант реализации всего этого дела. Сайт сам уже не живой (в плане юзеров), но можно зарегаться и полазить посмотреть если интересно :)
Проблема сайтов на ajax'e в том, что может загружаться один и тот же скрипт N раз.

К примеру если на вашем сайте клацать по «home», то появляется эквивалентное щелчкам количество скриптов «anonymous». А это очень заметно затормаживает браузер.

У самого такая проблема.
Я похожую проблему решал, но для jQuery mobile. Хотелось подгружать скрипт только при попадании юзера на определенную страницу, но не подгружать его при повторном заходе.

Решение такое — вместе со страницей мы передаем имя функции, которая должна быть выполнена после загрузки, и скрипт, в котором она объявлена. Если такая функция есть, то вызываем ее, иначе грузим скрипт.

В коде это выглядит как-то так:
$(document).delegate("div:jqmData(role='page')", 'pageinit', function(){
    var page = $(this);
    var processor = page.jqmData('processor');
    var source = page.jqmData('source');
    if (processor && source) {
        if (window[processor]) {
            window[processor]()
        }
        else {
            $.getScript(source);
        }
    }
})

А в HTML-шаблоне в код страницы добавляем:
<div data-role="page" id="pageID" data-source="/static/mobile/js/myScript.js" data-processor="processMyPage">

Переделать на не jquerymobile думаю особого труда не составит. Единственное, что я поправил бы сейчас — фунцкию-processor вызывал бы не напрямую в скрипте-source, как у меня, а в callback'е для getScript

А вообще мне самому интересно, как другие решают такую проблему.
Есть такие случаи, когда загрузка скрипта необходима в любом случае, даже если он уже загружен.

И удалять ранее загруженную копию скрипта невозможно.

Это если чисто все ajax.
Есть такие случаи, когда загрузка скрипта необходима в любом случае, даже если он уже загружен.

Очень интересно узнать про такие случаи…
Есть страница. На нее ajax'om загружается форма(jquery.fileupload), которая сама же через ajax передает файлы.

Все скрипты (более 6) можно загружать единожды, кроме того, который инициализирует определенную форму как форму, относящуюся к данному fileupload через вызов функции и передаче ей определенных параметров.

То есть… можно было сделать что бы событие накидывалось через .live() или другими способами, но для этого нужно переписывать довольно таки не малый скрипт.
Статья хорошая, просто маленькое дополнение: для фоновой загрузки, помнится, есть rel=«prefetch» для ссылок или link/meta. Поддерживается пока, правда, насколько помню, только в FF и Chrome, зато силами браузера, без лишнего кода :)
при таком способе нужно очень тщательно писать js код, что бы избежать memory leak
>Достаточно отдавать этот html напрямую, а не в виде json в случаях, когда запрос пришел не из ajax. Как это понять? При запросах из ajax будем передавать дополнительный параметр ajax=1, так мы всегда сможем различить откуда пришел запрос и как отдавать результат.

Достаточно на серверной части проверить http_x_requested_with на наличие XMLhttpRequest
Первый прием (подгрузка через AJAX) мы использовали еще два года назад или три :)… прикрутили к нашему фреймворку
единственный минус, как оказался, это так много накрутили JS, что для простой выдачи стр. со сылками (например поисковая выдача ) — нужно писать кучу JS кода. В общем, скорость разработки немного уменьшилась…
Статья в качестве обзорной — просто отличная, «все в одном». Однако видно, что у автора маловато опыта — некоторые места в коде удивляют (типа доступа к свойствам location через jquery.attr или использование extend для добавления свойства в объект). Но это ни в коей мере не умаляет заслугу автора, который скомпоновал такой отличный материал.
Или использование setInterval() для проверки загруженности доп. страниц, вместо коллбека.
Хочу заметить, что подгрузка AJAX имеет небольшой минус: плохо(или почти нет) индексируется.
Для некоторых сайтов это может быть критично.
Хотя, я читал, что пара лет назад Гуугль делает определенные шаги в этом направлении.
Все зависит от подхода. Если все AJAX-ссылки сделаны через хеш-тег (yoursite.com/#/users/akalend), то достаточно заменить хеш-тег на #! Тогда Google будет запрашивать у вашего сайта URL yoursite.com?_escaped_fragment_=/users/akalend
Вот ссылка на документацию у Google — developers.google.com/webmasters/ajax-crawling/docs/getting-started

Если же использовать history.pushState, то URL вообще не отличается ajax/не-ajax. При запросе не-ajax'ом отдается полная страница.
Only those users with full accounts are able to leave comments. Log in, please.