Во первых, не обязательно одного. На следующей странице может также изменится содержание правой колонки, 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+Клик