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

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

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

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

Очевидно же, если js нет, то синхронно, через http и html.

  
а как можно на html послать HTTP запрос? Поделись плиз.

Logo
ИМХО 

AJAX для сайтов можно применять только в очень маленьких количествах и очень осторожно. 

В свое время я писал такой пост: 
http://forum.vingrad.ru/forum/topic-285228...y2056408/0.html  

Пост старый и уже не все ссылки на примеры там работают.  


Насчет "сделать Ajax сайт, который работал бы и без JS (точнее имел бы вторую версию, работающую без JS)":
Теоретически можно. Но готовых фреймворков я не встречал. Да и над реализацией нужно будет попотеть. 
Какая тут сложность? - должно быть соответствие URL контенту: т.е. в AJAX версии при изменении содержимого какого-нибудь элемента должен меняться URL. И должна существовать другая версия сайта, без использования JS, которая по данному URL выдавала бы соответствующий контент.  

Это сообщение отредактировал(а) Vasay - 29.5.2012, 11:28

Да, есть такое дело...

Мне кажется это можно было бы реализовать таким концептом

•  Серверный шаблонизатор, как и клиентский на 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 генерирует новые виджеты без обновления страницы.
•  Так же объект виджета может иметь параметры конструктора, не передающиеся на сервер. Например параметры, обозначающие открытие/закрытие пункта меню

Может я не правильно Вас понял, но мне показалось, что в Вашем варианте все как-то сложно. Зачем, например, отправлять на сервер дерево состояний виджетов?

ИМХО, можно сделать проще:

есть страница состоящая из виджетов. Каждый виджет имеет состояние. Состояние всех виджетов закодировано в URL страницы.

Допустим, у нас есть выиджет, со списком товаров. Показывается 10 товаров. Есть кнопка "показать следующие 10". 

При ее нажатии, при наличии js, срабатывает событие "он клик", запускается скрипт обработки, происходит обращение к некоему сервису на нашем сайте, который должен выдать следующие 10 товаров (общение может происходить, например c помощью json). После обновления товаров в виджете скрипт меняет в URL соответствующий параметр, отвечающий за состояние конкретного виджета, блокирует переход по ссылке  и меняет "href" кнопки  "показать следующие 10" для того что бы она вела уже на следующие 10 товаров.

Если js нет или обращение первое, то происходит переход  ссылке кнопки "показать следующие 10". На нашем сайте запускается некий конструктор страницы, который по состоянию виджетов (переданному в URL ссылки) создает страницу со всеми виджетами.  

Забей!
Мало того, что процент НЕиспользования js на клиентских машинах пренебрежительно мал, так еще они попадают под корпоративный сегмент, который в подпвляющем количестве неинтересен сайту.
Судя по акцентам, как мне показалось, речь может идти о мобильной платформе - смартфонах и телефонах, где зачастую или js отключен, или его нет, или серьезные ограничения. Есть такое дело. Но тут настолько разношерстная компания, что делать универсальный сайт "для всего" - это гораздо затратнее и хуже, чем делать под десктоп и мобильную платформу раздельно. Для мобилок при запросе смотрим заголовки и "подсовываем" другую страницу. Либо при первом входе определяем модель, и в зависимости от нее не только можем "дать" клиенту сайтик под его разрешение, но и проинспектировать свойства и дать выбор - показывать ему обычный сайт или мобильный; понятно, при обычном риска по поводу js он берет на себя.

Гугль Бот тоже не интересен сайту? 

Хранить состояние ВСЕХ виджетов в url проблематично, url будет длинный и не ЧПУ.



При навигации по страницам редко когда обновляется весь контент полностью. Обычно меняются центральные виджеты, иногда виджеты в правой/левой колонке. Что бы знать, что изменилось, серверу нужно знать, что было на предыдущей странице.


Именно в данном конкретном случае я бы вообще сделал для no javascript обычный пейджер. Поисковику будет странно видеть кучу похожих страниц, причем страница при будет постепенно разрастается, нагружая как загрузку страницы (размер), так и выборку из БД.


Да, создание фреймворка с такой структурой весьма сложно. Использование же, как мне кажется, не должно быть сильно сложнее обычных action-based фреймворков.

Я думаю, при использовании Ajax а ЧПУ придется забыть.




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




Так для версии "no JS" и получается обычный пэйджинг, а для версии с JS - динамическое обновление товаров на странице, без перезагрузки страницы. 

А как знать, какие виджеты будут на следующей странице?


Мне показалось, что имеется ввиду постоянное увеличение размера страницы, добавляя нужное количество новостей, в зависимости от url. Да, обычный пейджер, с номерами страниц, и ссылками на первую и последнюю страницу. 


Ну почему, если сделать как следует, то можно. Тот же twitter тому пример. 

Так страница не меняется. Меняется содержимое одного виджета.



В простом частном случае, можно сделать.  В случае если мы хотим создать универсальную систему с набором виджетов - то придется хранить состояние всех виджетов в URL, при этом о ЧПУ придется забыть. 

Во первых, не обязательно одного. На следующей странице может также изменится содержание правой колонки, etc.
Во вторых, заранее неизвестно же, как именно он изменится. Если перейти со страницы каталога товаров на карточку товара, там будет контент товара. А если перейти на страницу faq, там будет содержание faq. И так далее.


Не обязательно в URL, можно например как я описал, в JS переменной, как я описал, содержащей состояние виджетов. А к URL на сервере будет привязано другое состояние виджетов - на следующей странице.

Так тогда мы снова огребаем все проблемы Ajax-а из-за несоответствия URL контенту. 

В смысле? Пока не вижу, где подвох.

К примеру на странице есть такие виджеты


При загрузке следующей страницы товаров приходит ответ



При обращении на страницу товара приходит



Можно перейти на страницу с полностью измененным дизайном


P.S. ajax псевдокод примерный

Добавлено через 12 минут и 20 секунд
Если на странице товара нажать "показать комментарии" (пускай виджет комментариев добавляется в centralLayout виджета root) то



Это сообщение отредактировал(а) Logo - 9.6.2012, 18:13

Ну, если состояния виджетов хранится в JS переменной, а не в URL, то что будет, если мы передадим ссылку на страницу, скажем, по icq?
Состояние виджетов, ведь, не передастся.

На каждый URL сервер знает состояние виджетов на этой странице (по умолчанию) и таким образом при первой загрузке/nojavascript генерирует страницу основываясь на классах виджетов.
К примеру карточка товара /article/104
Дерево виджетов

Logo, 

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

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

Но если виджетов на странице много, и каждый виджет имеет много параметров для хранения состояния, то с ЧПУ уже все будет грустно.

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

где абра-кадабра - URL- кодированная строка параметров каждого виджета.  

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

В качестве примера еще, тот же вконтакте с относительно понятными URL.

Logo, 



Если мы строим ajax сайт по канонам построения классических сайтов где в 90% все сводится к List,Edit,Update,Delete,Insert (URL, соответственно, имеет вид site.com/имя класса сущности/действие над сущностью/id сущности) то вопрос - а нафига нам ajax. Кроме лишних заморочек ничего не получим. 

Если мы хотим использовать AJAX для создания компонентных интерфейсов RIA - то мы упираемся в проблемы, про которые я говорил выше.

Причем, подобный подход и без упора на AJAX компоненты упирается в эти проблемы - см. портальные фреймворки. Из тех, с которыми я имел дело, наиболее адекватен LifeRay, по крайней мере при использовании стандартных портлетов ( читай - виджетов ) его разработчики добились соответствия URL контенту. И местами смогли даже добиться вменяемых URL.

При создании Ajax web фреймворка примерно на такую идеологию я бы и равнялся. 

Для того же, для чего вообще используется AJAX при создании обычных сайтов (не RIA).

•  Уменьшение трафика и скорости загрузки страницы
•  Отсутствие необходимости ререндерига всей страницы, тогда как обновилась лишь ее часть
•  Сохранение состояния виджетов с необязательным сохранением состояния, и стандартных компонентов браузера (input'ы, scroll, focus, и так далее)
•  Это круто и модно  Что немаловажно для заказчика.

RIA - это RIA. Согласитесь, при создании RIA приложения без AJAX не обойтись в любом случае.



Да, возможно стоит что-то позаимствовать из портлет ориентированных фреймворков. Лично я пока не работал с портлетами и компонент ориентированными фреймворками, только с обычными action-based.

Применения Ajax  в малых дозах - рейтинг товара, добавление товара в корзину, добавление коммента без перезагрузки страницы вполне оправданы.  При этом, это без проблем прикручивается к стандартным фреймворкам и движкам.  Но тут и париться насчет индексации, соответствия URL контенту - не надо. 



Попытки сделать круто и модно с большим количеством ajax-а чаще всего все заканчивается сменой на стандартное решение на базе стандартного фреймворка или движка.



Из личного опыта использования RIA интерфейсов в качестве пользователя - глаза б мои этого не видили :-( Юзабилити, обычно, на нуле ( админку godaddy 3х летней давности я вспоминаю как страшный сон! И я знаю очень много людей, переставших быть их клиентами из-за новой админки, а godaddy в ее разработку не один миллион $ вложил. ). 

Конечно, если сделать примерно то, что мы с Вами обсуждаем - многие проблемы решатся.  Но удастся ли сделать все красиво и с вменяемым количеством багов? Например интерфейс яндекс почты по мере своей Ajax-изации  бесит меня все больше и больше. Не всегда помогают даже оперативно вставляемые костыли. 

А интерфейс AdWords безбожно тормозящий на нетбуке это нормально? Причем я не могу сказать что он стал удобней старого интерфейса.  

Да и работоспособность гугловских сервисов (включая поиск) в Опере как-то не радует. 

Так что мое ИМХО, ajax базирующиеся web интерфейсы - зло.  Конечно,  поэкспериментировать можно, но оставив пользователям выбор - использовать ajax интерфейс, или обычный. 

Это сообщение отредактировал(а) Vasay - 12.6.2012, 22:15

В Яндекс почту захожу макс раз в месяц, но интерфейс Gmail вполне нравится.



Здесь в немалой степени зависит от качества реализации и предпочтений пользователя. Конечно, у обоих вариантов есть свои преимущества и недостатки. Простой HTML интерфейс хорош хотя бы тем, что будет работать везде, хоть даже в links.

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




Вот с этим и проблема. 

Это сообщение отредактировал(а) Vasay - 13.6.2012, 20:38

Ctrl+Клик

Такой фитчи не знал. Стандартными способами (средняя кнопка мыши, меню по правой кнопке) не открывает (а яндекс, сделал стандартное поведение для своего ajax интерфейса, и при этом еще и обычный не ajax оставил).

Правда, костыль гугль не допилил - в том виде в котором открывается письмо нет управляющих кнопок (удалить, в спам....).

п.с. если вернуться к теме, с которой мы начали - разработка ajax фреймворка, то яндекс почту я бы взял в пример - как надо делать Ajax Web интерфейс. Есть, конечно, некоторое количество багов (которые они пытаются исправлять), но в целом их интерфейс ведет себя весьма предсказуемо для пользователя, в отличие от ajax интерфейсов гугль сервисов. Гугль, конечно, может себе такое позволить - от него все равно народ никуда не денется, а вот зайдя на страницу какого-нибудь интернет магазина и не догадавшись, что новые вкладки нужно открывать через Ctrl, я бы не просмотрел много товаров.

Ctrl+Клик в числе стандартных способов, я часто так новые вкладки открываю. Да, яндекс обернул заголовок письма в ссылку, а у гугла обычные span'ы. Почему - хз. Может от того что клики можно перехватить и использовать ajax механизм, а меню по правой кнопке ни как не перехватить.
Так же любопытно, что если скопировать url открытого письма в google, и вставить на новую вкладку, он ничего не загрузит. Но тем не меннее, если нажать обновить на уже открытой вкладке с письмом, оно обновится нормально.


В спам, переслать, ответить там есть, менюшка в правом верхнем углу. А удалить действительно не вижу, странно.


Переносимость ajax интерфейса с нуля конечно реализовать сложнее, но при кроссбраузерной js библиотеке/фреймворке, в принципе, сложность пожалуй, лишь чуть чуть выше, чем у обычного HTML.

Добавлено через 10 минут и 39 секунд

Видимо, он так и делает, загружая контент письма основной страницей, и создавая через JS вторую. При обновлении window.opener не сбрасывается, контент письма новая вкладка берет из основной.

При закрытии основной вкладки он так же предупреждает о закрытии остальных, правда реально они не закрываются, лишь очищается контент (google chrome и firefox).