Привет!

Подскажите плиз какой AJAX фреймворк лучше подходит для поставленной задачи:
- Индексируется (эхххх, GWT сразу отпадает ...).
- Позволяет обновление страницы инициированное сервером.
- Позволяет 100% изменение контента страницы (подробнее ниже).
- Желательно не мешается с HTML.
- Небольшой обьем.

Чуть подробнее: Задача - Фреймворк для:
- Создание сйта, т.е. чистый и быстрый html, индексация и скины. Это неосновное направление, но абс. необходимое.
- Создание динамичных веб-приложений, т.е. AJAX. Это как-раз основное назначение.
Разумная мысль по разделению этих вещей не удастся, должно быть 2 в одном и никак иначе.

Как думаю решить
В идеале я бы взял GWT, но он не индексируется! Потому:
Все действия свожу к 2м вещам - запросам Get и AJAX ( Post не использую вообще! ), поскольку поисковику абс. достаточно Get (он получит чистый HTML и навигацию по ссылкам) а вся атрибутика веб-приложения, формы и т.д. может работать через AJAX (получаем 100% динамический интерфейс и 100% привычные закладки и переходы по страницам по ссылке).

Про сервер-сайд - я использую самописный фреймворк(не MVC, похож на JavaSWT или на Delphi), который хранит в памяти все дерево компонентов, и сделать любой кусок HTML-DOM по запросу AJAX оч. просто.
Все детали работы с AJAX тулом будут инкапсулирована в сервисном класе. При создании веб-приложений разработчики ни разу не будут знать про AJAX. Поэтому, собственно, удобства работы с библиотекой AJAX особого значения не имеют, только функционал.

Что выбрать?
- YUI - думаю eго, тяжеловат и там еще куча всего и я еще не совсем понял как все это сделать, но выглядит красиво :)
- prototypejs
- jQuery
- Dojo
- script.aculo.us
- Что-то еще?

Спасибо! :)

авторЭто недавно уппомянутый Server-Push. Такая технология пока еще не реализована во всех браузерах, хотя прогресс есть. Ориенироваться на нее не имеет пока что смысла. Данные просто перезапрашиваются клиентом через промежутки времени. И сервер дает новый контент.
Увы так.
Все верно, я имел ввиду что на JS будет таймер, который перезапрашивает через промежутки времени обновления у сервера. Просто хотелось бы чтобы фреймворк это уже поддерживал а не дописывать самому на JS.
Про Server-Push я не знал :).

автор1) индексация мало зависит от фреймворка, она зависит от собственных рук. В идеале тебе нужно наваять такой сайт, который будет работать полностью с отключенным яваскриптом, а с включенным - скрипт наращивает функционал для клиента поверх существующей структуры.
2) вот только не надо использовать GET для апдейта данных :)
1. При том подходе что я описал так и получится, при выключеном JS сайт полностью доступен для просмотра и навигации но не для обновления и работы с приложениями.
Под индексацией имелл ввиду чтобы HTML структура сохранялась. Например, если загрузить страницу построеную на GWT, то из контента там будет всего-лишь 1 строчка на JS.
2. Я буду использовать асинхронный Post.

Мысль пришла. Если я вместо Post делаю всегда AJAX-Post, то веть фактически мне не нужен тэг <form> и я могу запросто обойтись без него, просто определив в AJAX список всех полей которые я хочу получить.
Правда еще не проверил будет-ли реально так работать, на днях проверю :)

авторИ если "Позволяет 100% изменение контента страницы" - о каком индексировании идёт речь?Интерфейс можно разделить на 2 части: которую важно индексироват, и которая не нужна. Для первой части важен html, ссылки, закладки, для второй нет.
Решение - ссылки важны для индексирования, поэтому я их оставляю, но все остальное для индексирования не важно, поэтому я его выполняю через AJAX.
Пример - берем этот форум, все кроме ссылок делаем через АJAX, он что перестанет от этого быть индексируемым?

авторЕсли всё реализовано в "сервисном класе" зачем тогда какой-то "фреймворк"?
Потому-что я не знаю достаточно хорошо ни JavaScript ни тонкости всех этих асинхронных вызовов (например ту-же загрузку файла на сервер асинхронно не так просто сделать). Поэтому мне нужна библиотека которая все это сделает.
С другой стороны, API этой библиотеки всеравно достаточно низкоуровневый, поэтому она будет закрыта более высокоуровневой абстракцией.

авторА чего тогда разработчики делать будут?
Они будут работать, но GUI будет строится принципиально по другому. Не так как в PHP/RoR/а-ля MVC/...
Будет скорей похоже на Delphi/Java Swing/GWT/SWT. T.e. разработчики вообще не будут сталкиватся ни с HTML ни с JavaScript ни вообще напрямую с Web.

авторВообще не понятно, что автор получить хочет. Да и зачем?
Потому что то, что называют в веб MVC и что пишет на первой странице 99% веб фреймворков на самом деле полная хyета и ни разу не нормальный MVC. Пример - хер сделаеш КОМПОНЕНТ (вместе с бизнеслогикой, а не кучу всяких инклудов в множестве темплейтов) - форум так чтобы использовать его в любом месте приложения (т.е. как не в веб интефейсах).
И именно поэтому Гуглы, Яху и Саны разрабатывают всяческие спецификации портлетов, виджетов, и прочего.
Есть несколько вариантов которые решают этот вопрос, но они все с**а не индексируются (GWT, wingS, echo 2) либо оч. неудобны и сложны (Tapestry, Wicket)!!!
Поэтому я уже 4 месяц изобретаю свой велосипед.

авторА чем же гвт не нравиться? Можно часть страницы хтмл, а часть гвт. Кстати технология - баловство, но баловство от гугла - дорогого стоит.
Может Вам плюнуть и перейти на аспнет или JSP?Часть HTML часть GWT можно, НО! разработчикам нужно будет знать сразу 2 разных технологии, GWT всетаки довольно много весит, там не пара скриптов а целый движок. Но основной минус, то что из-за мешанины думаю будет сложно с этим работать.
GWT баловство, хз, мои друзья на нем достаточно мощный проект делали, не знаю в какой области, но их контора мелкими и средними не занимается.

авторЮзайте. ИМХО создавать туулзы не зная технологий слишком малоперспективно.Абс. верно. Как же мне бл* не хотелось заново все это изобретать, ...
И, ..., я в теме вобщем-то :), с JEE, 5 лет знаком, как и с JSF, JSP. С JаваScript, дизайнами и т.д. напрямую правда никогда дел не имел и иметь не хотел, а вот-же блин пришлось ...
Верю, что если очень сильно мозги напрягу, то осилю :)

авторКонечно перестанет. Щас погуглил свой логин - на этом форуме себя нашёл. К тому же, нормальный форум на аяксе не сделать, т.к. таких ссылочек не будет.Может я что-то не понимаю, или обяснаю плохо, хз. Ну вот взяли, GET оставили, а POST заменили на AJAX, и что, от этого индексация пострадает?
Про ссылку не понял. Ссылка как ссылка, ну еще с #. Чесно говоря, меня на самом деле не столько ссылки интересуют как поисковики и закладки, и если даже какой-то там специфичный функционал и обрежется, ну и фиг с ним, мне он не нужен :).

По теме, я выбрал YAHOO YUI . Думаю, это то что надо.

ОФФ
Щас вот изучаю как загружать файл через AJAX, бл*, ебанутcя фреймы какие-то там невидимые создавать ... :)

Добавлю, по поводу движков какие + и - после беглого просмотра. В JS я не силен, так что детали реализации не оценивал.

YUI
+ Первоклассные примеры и документация.
+ Полностью законченное целое решение, есть все.
+ Надежный, быстрый, ведется активный девелопмент.
+ Поддержка от YAHOO.
+ YAHOO сама использует его, т.е. генерал боевой а не парадный.
+ Свой WYSIWYG с оч хорошим дизайном.
+ Встраивается в любой сервер-сайд технологию
+ Красивый внешний вид
+ Простой, понятный и единообразный API.

- Нет тем
- Demo app features explorer у них не особо, не впечатлился. Тормозная мeшанина не пойми чего. Не для таких задач YUI создавался.

prototypejs
+ Дешево и сердито, просто, как только можно, но не проще.
+ весь API можно описать в двух строчках.
- Маловато документации и примеров.
- Нет готовых элементов, разбираться самостоятельно как с его помощью загружать файлы и интегрировать его со строронним WYSIWYG я не хочу.
- Убогий сайт (ну если ты делаешь UI, то как-то странно самому быть без сапог).

jQuery
+ Клевый сайт
+ Хорошие демки и примеры
+ Документация нормальная
+ API нормальный.
+ темы есть
+ вроде самый популярный
- Каким только боком этот jQuery не трахают и куда только не прикручивают. Куча хлама всяких непонятных плагинов и прочего отстоя.
- Думаю что изначально он создавался как утилита для создания визуальных эффектов но потом разросся в универсальное решение и туда чего только не добавили (но это хз, мне так показалось).
- Много всякого хлама (эфекты какие-то, рыбий глаз и прочая хуета) а WYSIWYG нету.

Dojo
Давно смотрел, не впечатлился. Опять-же, всякие эффекты которые мне нафиг не нужны. Демки слабые. АПИ не смотрел.

авторПотому что, то что выполняется аяксом - на страничке появляется динамически и в её исходнике (правая кнопка мыши) отсутствует.
Да! Но Гуглу не нужно знать какая воронка продаж у менеджера или сколько товаров он продал! Вобщем я понял, я не полно обяснил что имел ввиду.
Вобщем, у разработчиков будет выбор. Все, что дольжно быть видно Гугли и проиндексировано можно будет сделать видимым. А все что не нужно (детали, внутренние приложения, CRUD, ... ) проще и быстрее сделать 'one page' AJAX.

Ну вот я добавляю комментарий этот сейчас на форуме, разве нельзя его сделать AJAX? Можно, и нужно :). И никто при этом не потеряет HTML, потомучто при следующем запросе этой страницы он будет виден по правой кнопке )

ZK посмотрел, смотрел его еще год назад, тогда не было УРЛ и закладок, теперь есть. Но все равно он тяжеловат и немного не то.