Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java EE (J2EE) и Spring > Ajax сайт с поддержкой no javascript

Автор: Logo 25.5.2012, 20:47

Посмотрел некоторые Java фреймворки, понравился демо сайт полностью на ajax (Google Web Toolkit) http://3d-port.com/ Однако тут есть существенный минус - с отключенным JavaScript не работает. Существуют ли фреймворки, позволяющие сделать ajax сайт, работающий также и при отключенном JavaScript?

Автор: Stolzen 25.5.2012, 21:15

Нет. Знаете как AJAX расшифровывается?

Автор: Logo 25.5.2012, 21:57

В курсе. Но теоретически не вижу препятствий к тому, что бы использовать одинаковый шаблонизатор на сервере и клиенте, и в случае отсутствия javascript генерировать то же самое на сервере.

Автор: Nofate 25.5.2012, 23:35

А данные то вы как будете асинхронно гонять без JS?

Автор: Logo 26.5.2012, 14:27

Цитата(Nofate @ 25.5.2012,  23:35) А данные то вы как будете асинхронно гонять без JS? Очевидно же, если js нет, то синхронно, через http и html.

Автор: Samotnik 28.5.2012, 23:45

Цитата(Logo @  26.5.2012,  14:27 ) Очевидно же, если js нет, то синхронно, через http и html.     а как можно на html послать HTTP запрос? Поделись плиз.

Автор: Vasay 29.5.2012, 11:27

Logo ИМХО  AJAX для сайтов можно применять только в очень маленьких количествах и очень осторожно.  В свое время я писал такой пост:  http://forum.vingrad.ru/forum/topic-285228/anchor-entry2056408/0.html   Пост старый и уже не все ссылки на примеры там работают.   Насчет "сделать Ajax сайт, который работал бы и без JS (точнее имел бы вторую версию, работающую без JS)": Теоретически можно. Но готовых фреймворков я не встречал. Да и над реализацией нужно будет попотеть.  Какая тут сложность? - должно быть соответствие URL контенту: т.е. в AJAX версии при изменении содержимого какого-нибудь элемента должен меняться URL. И должна существовать другая версия сайта, без использования JS, которая по данному URL выдавала бы соответствующий контент.

Автор: Logo 5.6.2012, 20:36

Цитата Какая тут сложность? - должно быть соответствие URL контенту: т.е. в AJAX версии при изменении содержимого какого-нибудь элемента должен меняться URL. И должна существовать другая версия сайта, без использования JS, которая по данному URL выдавала бы соответствующий контент.   Да, есть такое дело... Мне кажется это можно было бы реализовать таким концептом  Серверный шаблонизатор, как и клиентский на JavaScript(V8), DOM tree based шаблонизатор, вроде PURE  Сайт состоит из набора виджетов, каждый объект виджета может иметь поля layout, содержащие массив дочерних виджетов. Начинается дерево виджетов с корневого виджета, который допустим имеет поля вывода leftColumn, rightColumn, content. Также это дерево в JSON содержит класс виджета и параметры его конструктора (например id статьи, для виджета отображающего содержание статьи)   При обращении к определенному url генерируется дерево виджетов (содержащее для каждого виджета его класс, параметры конструктора, и дочерние виджеты). Если это первое обращение к этому url (или no JavaScript) то по этому дереву вызываются конструкторы виджетов, которые извлекают данные (часть класса виджета, отвечающая за Controller), и на основе шаблонизатора класса виджета генерируют html. Если обращение к url'у идет из javascript (со специальным параметром), то на сервер отправляется дерево виджетов, описывющее их состояние. Сервер также генерирует дерево виджетов для этого url'а, и сравнивает его с переданным из JS деревом. Виджеты, оставшиеся без изменения, удаляются из дерева, те виджеты, которых не должно быть на этой странице, помечаются для удаления, diff дерева получается. Затем по дереву генерируются новые виджеты, но их данные передаются не в шаблонизатор, а отправляются в дереве на клиент. Так же JS передает классы виджетов, шаблоны для которых уже загружены, и если новые виджеты на этом url'е принадлежат новым классам, то в ответе так же передается шаблон (и js код, если нужен), для новых виджетов. Используя шаблоны и данные js генерирует новые виджеты без обновления страницы.  Так же объект виджета может иметь параметры конструктора, не передающиеся на сервер. Например параметры, обозначающие открытие/закрытие пункта меню

Автор: Vasay 5.6.2012, 22:55

Цитата(Logo @  5.6.2012,  20:36 )  При обращении к определенному url генерируется дерево виджетов (содержащее для каждого виджета его класс, параметры конструктора, и дочерние виджеты). Если это первое обращение к этому url (или no JavaScript) то по этому дереву вызываются конструкторы виджетов, которые извлекают данные (часть класса виджета, отвечающая за Controller), и на основе шаблонизатора класса виджета генерируют html.Если обращение к url'у идет из javascript (со специальным параметром), то на сервер отправляется дерево виджетов, описывющее их состояние. Сервер также генерирует дерево виджетов для этого url'а, и сравнивает его с переданным из JS деревом. Виджеты, оставшиеся без изменения, удаляются из дерева, те виджеты, которых не должно быть на этой странице, помечаются для удаления, diff дерева получается. Затем по дереву генерируются новые виджеты, но их данные передаются не в шаблонизатор, а отправляются в дереве на клиент.Так же JS передает классы виджетов, шаблоны для которых уже загружены, и если новые виджеты на этом url'е принадлежат новым классам, то в ответе так же передается шаблон (и js код, если нужен), для новых виджетов.Используя шаблоны и данные js генерирует новые виджеты без обновления страницы. Может я не правильно Вас понял, но мне показалось, что в Вашем варианте все как-то сложно. Зачем, например, отправлять на сервер дерево состояний виджетов? ИМХО, можно сделать проще: есть страница состоящая из виджетов. Каждый виджет имеет состояние. Состояние всех виджетов закодировано в URL страницы. Допустим, у нас есть выиджет, со списком товаров. Показывается 10 товаров. Есть кнопка "показать следующие 10".  При ее нажатии, при наличии js, срабатывает событие "он клик", запускается скрипт обработки, происходит обращение к некоему сервису на нашем сайте, который должен выдать следующие 10 товаров (общение может происходить, например c помощью json). После обновления товаров в виджете скрипт меняет в URL соответствующий параметр, отвечающий за состояние конкретного виджета, блокирует переход по ссылке  и меняет "href" кнопки  "показать следующие 10" для того что бы она вела уже на следующие 10 товаров. Если js нет или обращение первое, то происходит переход  ссылке кнопки "показать следующие 10". На нашем сайте запускается некий конструктор страницы, который по состоянию виджетов (переданному в URL ссылки) создает страницу со всеми виджетами.

Автор: IDVsbruck 6.6.2012, 15:28

Цитата(Logo @  25.5.2012,  20:47 ) Однако тут есть существенный минус - с отключенным JavaScript не работает. Существуют ли фреймворки, позволяющие сделать ajax сайт, работающий также и при отключенном JavaScript?  Забей! Мало того, что процент НЕиспользования js на клиентских машинах пренебрежительно мал, так еще они попадают под корпоративный сегмент, который в подпвляющем количестве неинтересен сайту. Судя по акцентам, как мне показалось, речь может идти о мобильной платформе - смартфонах и телефонах, где зачастую или js отключен, или его нет, или серьезные ограничения. Есть такое дело. Но тут настолько разношерстная компания, что делать универсальный сайт "для всего" - это гораздо затратнее и хуже, чем делать под десктоп и мобильную платформу раздельно. Для мобилок при запросе смотрим заголовки и "подсовываем" другую страницу. Либо при первом входе определяем модель, и в зависимости от нее не только можем "дать" клиенту сайтик под его разрешение, но и проинспектировать свойства и дать выбор - показывать ему обычный сайт или мобильный; понятно, при обычном риска по поводу js он берет на себя.

Автор: Vasay 6.6.2012, 16:04

Цитата(IDVsbruck @  6.6.2012,  15:28 ) Забей! Мало того, что процент НЕиспользования js на клиентских машинах пренебрежительно мал, так еще они попадают под корпоративный сегмент, который в подпвляющем количестве неинтересен сайту. Гугль Бот тоже не интересен сайту?

Автор: Logo 6.6.2012, 21:56

Цитата ИМХО, можно сделать проще: есть страница состоящая из виджетов. Каждый виджет имеет состояние. Состояние всех виджетов закодировано в URL страницы. Хранить состояние ВСЕХ виджетов в url проблематично, url будет длинный и не ЧПУ. Цитата  Зачем, например, отправлять на сервер дерево состояний виджетов? При навигации по страницам редко когда обновляется весь контент полностью. Обычно меняются центральные виджеты, иногда виджеты в правой/левой колонке. Что бы знать, что изменилось, серверу нужно знать, что было на предыдущей странице. Цитата Допустим, у нас есть выиджет, со списком товаров. Показывается 10 товаров. Есть кнопка "показать следующие 10".  Именно в данном конкретном случае я бы вообще сделал для no javascript обычный пейджер. Поисковику будет странно видеть кучу похожих страниц, причем страница при будет постепенно разрастается, нагружая как загрузку страницы (размер), так и выборку из БД. Цитата Может я не правильно Вас понял, но мне показалось, что в Вашем варианте все как-то сложно. Да, создание фреймворка с такой структурой весьма сложно. Использование же, как мне кажется, не должно быть сильно сложнее обычных action-based фреймворков.

Автор: Vasay 6.6.2012, 22:30

Цитата(Logo @  6.6.2012,  21:56 ) Хранить состояние ВСЕХ виджетов в url проблематично, url будет длинный и не ЧПУ. Я думаю, при использовании Ajax а ЧПУ придется забыть. Цитата(Logo @  6.6.2012,  21:56 ) При навигации по страницам редко когда обновляется весь контент полностью. Обычно меняются центральные виджеты, иногда виджеты в правой/левой колонке. Что бы знать, что изменилось, серверу нужно знать, что было на предыдущей странице. Так надо отправить только запрос на новую информацию для изменяемого виджета. Цитата(Logo @  6.6.2012,  21:56 ) Именно в данном конкретном случае я бы вообще сделал для no javascript обычный пейджер. Поисковику будет странно видеть кучу похожих страниц, причем страница при будет постепенно разрастается, нагружая как загрузку страницы (размер), так и выборку из БД. Так для версии "no JS" и получается обычный пэйджинг, а для версии с JS - динамическое обновление товаров на странице, без перезагрузки страницы.

Автор: Logo 7.6.2012, 00:18

Цитата Так надо отправить только запрос на новую информацию для изменяемого виджета. А как знать, какие виджеты будут на следующей странице? Цитата Так для версии "no JS" и получается обычный пэйджинг, а для версии с JS - динамическое обновление товаров на странице, без перезагрузки страницы.   Мне показалось, что имеется ввиду постоянное увеличение размера страницы, добавляя нужное количество новостей, в зависимости от url. Да, обычный пейджер, с номерами страниц, и ссылками на первую и последнюю страницу.  Цитата Я думаю, при использовании Ajax а ЧПУ придется забыть. Ну почему, если сделать как следует, то можно. Тот же twitter тому пример.

Автор: Vasay 7.6.2012, 01:26

Цитата(Logo @  7.6.2012,  00:18 ) А как знать, какие виджеты будут на следующей странице? Так страница не меняется. Меняется содержимое одного виджета. Цитата(Logo @  7.6.2012,  00:18 ) Ну почему, если сделать как следует, то можно. Тот же twitter тому пример.  В простом частном случае, можно сделать.  В случае если мы хотим создать универсальную систему с набором виджетов - то придется хранить состояние всех виджетов в URL, при этом о ЧПУ придется забыть.

Автор: Logo 9.6.2012, 15:29

Цитата Так страница не меняется. Меняется содержимое одного виджета. Во первых, не обязательно одного. На следующей странице может также изменится содержание правой колонки, etc. Во вторых, заранее неизвестно же, как именно он изменится. Если перейти со страницы каталога товаров на карточку товара, там будет контент товара. А если перейти на страницу faq, там будет содержание faq. И так далее. Цитата В простом частном случае, можно сделать.  В случае если мы хотим создать универсальную систему с набором виджетов - то придется хранить состояние всех виджетов в URL, при этом о ЧПУ придется забыть.   Не обязательно в URL, можно например как я описал, в JS переменной, как я описал, содержащей состояние виджетов. А к URL на сервере будет привязано другое состояние виджетов - на следующей странице.

Автор: Vasay 9.6.2012, 16:52

Цитата(Logo @  9.6.2012,  15:29 ) Не обязательно в URL, можно например как я описал, в JS переменной Так тогда мы снова огребаем все проблемы Ajax-а из-за несоответствия URL контенту.

Автор: Logo 9.6.2012, 18:11

Цитата(Vasay @ 9.6.2012,  16:52) Цитата(Logo @  9.6.2012,  15:29 ) Не обязательно в URL, можно например как я описал, в JS переменной Так тогда мы снова огребаем все проблемы Ajax-а из-за несоответствия URL контенту. В смысле? Пока не вижу, где подвох. К примеру на странице есть такие виджеты Код { //корневой виджет     class:"root",     centralLayout: [ //область вывода         { // виджет каталог             class: "catalog",             layout: [ //область вывода                 {  //виджет пейджер                     class: "catalogPager",                     constructor: [page:1]                 }             ]         }     ] } При загрузке следующей страницы товаров приходит ответ Код { //корневой виджет     class:"root",     centralLayout: [         {             class: "catalog",             layout: [                 {del: {class: "catalogPager", constructor: [page:1]}}, // виджет удаляется                 {add: {                                               // виджет добавляется                     class: "catalogPager",                     constructor: [page:2],                     contentVars: {                         //... переменные шаблона                     }                 }}             ]          }     ] } При обращении на страницу товара приходит Код {     class:"root",     centralLayout: [         {del: {class: "catalog"}},         {add: { // виджет товара           class: "article",           constructor: [id:104],           contentVars: {             //... переменные шаблона           }         }}     ] } Можно перейти на страницу с полностью измененным дизайном Код {del: {class:"root"}}, {add: {     class:"root2",     centralLayout: ...     leftLayout: ...     rightLayout: ... } P.S. ajax псевдокод примерный Добавлено через 12 минут и 20 секунд Если на странице товара нажать "показать комментарии" (пускай виджет комментариев добавляется в centralLayout виджета root) то Код {     class:"root",     centralLayout: [         { // виджет товара           class: "article",           constructor: [id:104],         },         {add:{             class: "comments",             constructor: [forArticle:104],             contentVars: {                 //... переменные шаблона             }         }}     ] }

Автор: Vasay 9.6.2012, 20:49

Цитата(Logo @  9.6.2012,  18:11 ) В смысле? Пока не вижу, где подвох. Ну, если состояния виджетов хранится в JS переменной, а не в URL, то что будет, если мы передадим ссылку на страницу, скажем, по icq? Состояние виджетов, ведь, не передастся.

Автор: Logo 9.6.2012, 22:37

На каждый URL сервер знает состояние виджетов на этой странице (по умолчанию) и таким образом при первой загрузке/nojavascript генерирует страницу основываясь на классах виджетов. К примеру карточка товара /article/104 Дерево виджетов Код { // корневой виджет, дизайн страницы   class: "root"    cenralLayout : [ // центральная колонка      { // виджет карточки товара        class: "article",        constructor: [id:104],      }   ],   leftLayout : [ // левая колонка      { //виджет меню         class: "menu"      }   ] }

Автор: Vasay 9.6.2012, 23:02

Logo,  Но состояние виджетов получаем "по-умолчанию". Т.е. если я изменю состояние виджета и пошлю Вам ссылку - Вы получите виджет в дефолтном состоянии

Автор: Logo 11.6.2012, 22:06

Если изменение виджета сопровождается изменением url - нет, почему же. Фактически на каждый url хранится состояние виджетов - и используется ЧПУ.

Автор: Vasay 12.6.2012, 12:24

Цитата(Logo @  11.6.2012,  22:06 ) Фактически на каждый url хранится состояние виджетов - и используется ЧПУ. Но если виджетов на странице много, и каждый виджет имеет много параметров для хранения состояния, то с ЧПУ уже все будет грустно. К тому же, чтоб избежать пересекания параметров разных виджетов, думаю, нужно будет делать кодирование строки параметров каждого виджета (вот тут ЧПУ точно в пролете). Т.е. URL приобретает примерно такой вид site.com/page?widgetID1=абра-кадабра-1&widgetID2=абра-кадабра-2......widgetIDN=абра-кадабра-N где абра-кадабра - URL- кодированная строка параметров каждого виджета.

Автор: Logo 12.6.2012, 19:37

Цитата Но если виджетов на странице много, и каждый виджет имеет много параметров для хранения состояния, то с ЧПУ уже все будет грустно. Ajax сайт в этом плане не уступает и превосходит обычный сайт. Количество и понятность URL не зависит от того, синхронный или асинхронный запрос идет к серверу. Для некоторых виджетов не имеет особого смысла сохранять состояние, напр. раскрывающееся меню-слайдер (раскрытые/скрытые пункты), и д.р. В качестве примера еще, тот же вконтакте с относительно понятными URL.

Автор: Vasay 12.6.2012, 20:22

Logo,  Цитата(Logo @  12.6.2012,  19:37 ) Ajax сайт в этом плане не уступает и превосходит обычный сайт. Количество и понятность URL не зависит от того, синхронный или асинхронный запрос идет к серверу.Для некоторых виджетов не имеет особого смысла сохранять состояние, напр. раскрывающееся меню-слайдер (раскрытые/скрытые пункты), и д.р. Если мы строим ajax сайт по канонам построения классических сайтов где в 90% все сводится к List,Edit,Update,Delete,Insert (URL, соответственно, имеет вид site.com/имя класса сущности/действие над сущностью/id сущности) то вопрос - а нафига нам ajax. Кроме лишних заморочек ничего не получим.  Если мы хотим использовать AJAX для создания компонентных интерфейсов RIA - то мы упираемся в проблемы, про которые я говорил выше. Причем, подобный подход и без упора на AJAX компоненты упирается в эти проблемы - см. портальные фреймворки. Из тех, с которыми я имел дело, наиболее адекватен LifeRay, по крайней мере при использовании стандартных портлетов ( читай - виджетов ) его разработчики добились соответствия URL контенту. И местами смогли даже добиться вменяемых URL. При создании Ajax web фреймворка примерно на такую идеологию я бы и равнялся.

Автор: Logo 12.6.2012, 21:04

Цитата Если мы строим ajax сайт по канонам построения классических сайтов где в 90% все сводится к List,Edit,Update,Delete,Insert (URL, соответственно, имеет вид site.com/имя класса сущности/действие над сущностью/id сущности) то вопрос - а нафига нам ajax. Кроме лишних заморочек ничего не получим.  Для того же, для чего вообще используется AJAX при создании обычных сайтов (не RIA).  Уменьшение трафика и скорости загрузки страницы  Отсутствие необходимости ререндерига всей страницы, тогда как обновилась лишь ее часть  Сохранение состояния виджетов с необязательным сохранением состояния, и стандартных компонентов браузера (input'ы, scroll, focus, и так далее)  Это круто и модно  Что немаловажно для заказчика. Цитата Если мы хотим использовать AJAX для создания компонентных интерфейсов RIA - то мы упираемся в проблемы, про которые я говорил выше. RIA - это RIA. Согласитесь, при создании RIA приложения без AJAX не обойтись в любом случае. Цитата Причем, подобный подход и без упора на AJAX компоненты упирается в эти проблемы - см. портальные фреймворки. Из тех, с которыми я имел дело, наиболее адекватен LifeRay, по крайней мере при использовании стандартных портлетов ( читай - виджетов ) его разработчики добились соответствия URL контенту. И местами смогли даже добиться вменяемых URL. При создании Ajax web фреймворка примерно на такую идеологию я бы и равнялся.  Да, возможно стоит что-то позаимствовать из портлет ориентированных фреймворков. Лично я пока не работал с портлетами и компонент ориентированными фреймворками, только с обычными action-based.

Автор: Vasay 12.6.2012, 22:11

Цитата(Logo @  12.6.2012,  21:04 ) Для того же, для чего вообще используется AJAX при создании обычных сайтов (не RIA).  Уменьшение трафика и скорости загрузки страницы  Отсутствие необходимости ререндерига всей страницы, тогда как обновилась лишь ее часть  Сохранение состояния виджетов с необязательным сохранением состояния, и стандартных компонентов браузера (input'ы, scroll, focus, и так далее)  Применения Ajax  в малых дозах - рейтинг товара, добавление товара в корзину, добавление коммента без перезагрузки страницы вполне оправданы.  При этом, это без проблем прикручивается к стандартным фреймворкам и движкам.  Но тут и париться насчет индексации, соответствия URL контенту - не надо.  Цитата Это круто и модно  Что немаловажно для заказчика. Попытки сделать круто и модно с большим количеством ajax-а чаще всего все заканчивается сменой на стандартное решение на базе стандартного фреймворка или движка. Цитата(Logo @  12.6.2012,  21:04 ) RIA - это RIA. Согласитесь, при создании RIA приложения без AJAX не обойтись в любом случае. Из личного опыта использования RIA интерфейсов в качестве пользователя - глаза б мои этого не видили :-( Юзабилити, обычно, на нуле ( админку godaddy 3х летней давности я вспоминаю как страшный сон! И я знаю очень много людей, переставших быть их клиентами из-за новой админки, а godaddy в ее разработку не один миллион $ вложил. ).  Конечно, если сделать примерно то, что мы с Вами обсуждаем - многие проблемы решатся.  Но удастся ли сделать все красиво и с вменяемым количеством багов? Например интерфейс яндекс почты по мере своей Ajax-изации  бесит меня все больше и больше. Не всегда помогают даже оперативно вставляемые костыли.  А интерфейс AdWords безбожно тормозящий на нетбуке это нормально? Причем я не могу сказать что он стал удобней старого интерфейса.   Да и работоспособность гугловских сервисов (включая поиск) в Опере как-то не радует.  Так что мое ИМХО, ajax базирующиеся web интерфейсы - зло.  Конечно,  поэкспериментировать можно, но оставив пользователям выбор - использовать ajax интерфейс, или обычный.

Автор: Logo 13.6.2012, 20:00

Цитата Например интерфейс яндекс почты по мере своей Ajax-изации  бесит меня все больше и больше.  В Яндекс почту захожу макс раз в месяц, но интерфейс Gmail вполне нравится. Цитата А интерфейс AdWords безбожно тормозящий на нетбуке это нормально? Причем я не могу сказать что он стал удобней старого интерфейса.   Да и работоспособность гугловских сервисов (включая поиск) в Опере как-то не радует.  Так что мое ИМХО, ajax базирующиеся web интерфейсы - зло.  Конечно,  поэкспериментировать можно, но оставив пользователям выбор - использовать ajax интерфейс, или обычный.  Здесь в немалой степени зависит от качества реализации и предпочтений пользователя. Конечно, у обоих вариантов есть свои преимущества и недостатки. Простой HTML интерфейс хорош хотя бы тем, что будет работать везде, хоть даже в links.

Автор: Vasay 13.6.2012, 20:36

Цитата(Logo @  13.6.2012,  20:00 ) В Яндекс почту захожу макс раз в месяц, но интерфейс Gmail вполне нравится. Честно сказать,  на мой взгляд - Яндекс хоть пытается чтоб его красивости не шли в разрез с юзабилити (не всегда, правда, получается. Их новая фишка в почте с отменой страниц и вводом кнопки "Еще письма", при нажатии на которую просто увеличивается число писем на странице - тот еще бред. Надеюсь вернут назад страницы ). А гугль даже серьезные просчеты не исправляет - типа "все равно от меня никуда не денетесь".  Открыть письма в новом окне/вкладке по-прежнему нельзя? Или неужели такая крупная компания как Гугль не может решить проблему с сохранением настроек поиска в Опере (слава Богу, хоть живой поиск стал отключаться, но изменить число результатов поиска на странице по-прежнему нельзя :-(  )? Цитата(Logo @  13.6.2012,  20:00 ) Здесь в немалой степени зависит от качества реализации Вот с этим и проблема.

Автор: Logo 15.6.2012, 14:01

Цитата Открыть письма в новом окне/вкладке по-прежнему нельзя? Ctrl+Клик

Автор: Vasay 15.6.2012, 15:00

Цитата(Logo @  15.6.2012,  14:01 ) Ctrl+Клик Такой фитчи не знал. Стандартными способами (средняя кнопка мыши, меню по правой кнопке) не открывает (а яндекс, сделал стандартное поведение для своего ajax интерфейса, и при этом еще и обычный не ajax оставил). Правда, костыль гугль не допилил - в том виде в котором открывается письмо нет управляющих кнопок (удалить, в спам....). п.с. если вернуться к теме, с которой мы начали - разработка ajax фреймворка, то яндекс почту я бы взял в пример - как надо делать Ajax Web интерфейс. Есть, конечно, некоторое количество багов (которые они пытаются исправлять), но в целом их интерфейс ведет себя весьма предсказуемо для пользователя, в отличие от ajax интерфейсов гугль сервисов. Гугль, конечно, может себе такое позволить - от него все равно народ никуда не денется, а вот зайдя на страницу какого-нибудь интернет магазина и не догадавшись, что новые вкладки нужно открывать через Ctrl, я бы не просмотрел много товаров.

Автор: Logo 15.6.2012, 17:20

Цитата Такой фитчи не знал. Стандартными способами (средняя кнопка мыши, меню по правой кнопке) не открывает (а яндекс, сделал стандартное поведение для своего ajax интерфейса, и при этом еще и обычный не ajax оставил). Ctrl+Клик в числе стандартных способов, я часто так новые вкладки открываю. Да, яндекс обернул заголовок письма в ссылку, а у гугла обычные span'ы. Почему - хз. Может от того что клики можно перехватить и использовать ajax механизм, а меню по правой кнопке ни как не перехватить. Так же любопытно, что если скопировать url открытого письма в google, и вставить на новую вкладку, он ничего не загрузит. Но тем не меннее, если нажать обновить на уже открытой вкладке с письмом, оно обновится нормально. Цитата Правда, костыль гугль не допилил - в том виде в котором открывается письмо нет управляющих кнопок (удалить, в спам....). В спам, переслать, ответить там есть, менюшка в правом верхнем углу. А удалить действительно не вижу, странно. Цитата п.с. если вернуться к теме, с которой мы начали - разработка ajax фреймворка, то яндекс почту я бы взял в пример - как надо делать Ajax Web интерфейс. Есть, конечно, некоторое количество багов (которые они пытаются исправлять), но в целом их интерфейс ведет себя весьма предсказуемо для пользователя, в отличие от ajax интерфейсов гугль сервисов. Гугль, конечно, может себе такое позволить - от него все равно народ никуда не денется, а вот зайдя на страницу какого-нибудь интернет магазина и не догадавшись, что новые вкладки нужно открывать через Ctrl, я бы не просмотрел много товаров. Переносимость ajax интерфейса с нуля конечно реализовать сложнее, но при кроссбраузерной js библиотеке/фреймворке, в принципе, сложность пожалуй, лишь чуть чуть выше, чем у обычного HTML. Добавлено через 10 минут и 39 секунд Цитата Может от того что клики можно перехватить и использовать ajax механизм, а меню по правой кнопке ни как не перехватить. Видимо, он так и делает, загружая контент письма основной страницей, и создавая через JS вторую. При обновлении window.opener не сбрасывается, контент письма новая вкладка берет из основной. При закрытии основной вкладки он так же предупреждает о закрытии остальных, правда реально они не закрываются, лишь очищается контент (google chrome и firefox).

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)