Посмотрел некоторые 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, при этом о ЧПУ придется забыть.