прет сем =)

есть задача следующего рода:

у меня есть некая интернетстраница состоящая как обычно из блоков с лева (меню) справа (реклама) и посередине (контент).. дело в следующем: 
я использую сторонние библиотеки яваксрипка куда мне пришлось самому встроить AJAX запросы для посылки сообщений на сервер.. например, юзер нажал на "фотоальбом".. был вызван яваксрипт, сделал что-то и через AJAX с клиента на сервер ушёл запрос.. затем с сервера  приходит содержание фотоальбома, которым я заполняю середину моей страницы.. и т.д. ( в общем ничего не обычного, кроме как по дороге используется куча яваскрипта)

вылезли следующие траблы:

- очень много нужно обрабатывать все различных параметров, посему:
- во первых, посколько JSF довольно серьёзная технология я бы тоже хотел её применитъ в своей интернетстранице.. посему я начал копать уже существующие frameworks..
- есть куча frameworks работающих с ajax-ом и jsf, например я попробовал ajax4jsf от jboss-a (здесь у меня вылезло куча проблем. к сожалению не все примеры предоставленые на странице работают. а те, что не работают (например, include) мне как раз-таки и нужны)
- здесь же вылазиет ещё такая проблема: я не могу на 100% использовать чей-либо framework и посему мне нужно как-то самому подключить мой ajax к jsf-у ( ума не приложу как это зделать побыстрее и не переписывать велосипед)
- покопался в технологии seam от jboss.. к сожалению такие же траблы ( не всё что представлено работает, а почему не работает я разобраться не могу )

может кто использовал собстренноручно написаынные запросы AJAX + JSF и может мне помочь здесь каким-либо советом?   

заранее БОЛЬШОЕ пасиба   

если вдруг не понятно, дополню, вот такие вот конструкции мне явно не подходят: 

String key = (String)request.getParameter("key");

хотелось бы всё привести к виду #{Bean.key}   

посмотрел примеры на:

GWT + JSF

ничего хорошего я не увидел.. хм..   

Это сообщение отредактировал(а) polosatij - 10.4.2007, 19:55

Большого отличия работы JSF + AJAX JavaScript от JSP + AJAX JavaScript нет. Ну формируешь ajax запросы к страничкам вида /ajax_response.jsf в отличии от /ajax_response.jsf. Ну и возвращает вам ajax запрос или xml, или текст, или Jason объекты, в зависимости от того, с чем ваш javascript потом будет работать.
Фреймворки, обычно, ставят задачу освободить программиста от работы с JavaScript вообще, типа, это сложно все. Ну и соответственно одно из мест их подключения является или сервлет или фильтр, который и обрабатывает ajax запросы. При работе с JavaScript напрямую можно и без этого обойтись.

хм.. погоди.. давай различим между: можно сделать и не хочу я так делать => зачем изобретать велосипед с приходящими параметрами?

я не хочу сам обрабатывать все приходяшие параметры, их не один два.. плюс позади стоит EJB.. а это значит мне придётся из приходящих параметров самому стоить бины.. хм.. а зачем, когда есть это уже в JSF?  

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


хм.. интересно.. как это нет?

- JSF: #{Bean.foobar} + faces-config.xml
- JSP request.getParameter('foobar') и дальнейший бред ( тут лучше servlet + какой-нибудь template тогда )

Выкинуть JSF и делать как  

polosatij
Две более менее нормальные технологии сочетающие jsf с ajax на данный момент -- ajax4jsf (добавляет ajax поведение существующим jsf компонентам) и icefaces (собственные компоненты, расширяющие jsf'овые ajax-поведением и разными дополнительными фичерами). Обе на данный момент влились в jBoss и будут развиваться в рамках Seam. Если сравнивать, то ajax4jsf дает только подход и возможность гибко работать с ajax в jsf окружении, в то время как icefaces предоставляет сразу достаточно богатые (на первый взгляд) компоненты, такие как табуляторы, таблицы, каленадри, статус коннекта и т.п. но, как показала практика, с огромным букетом багов и проблем.

не хочу я так.. это будет опять-таки изобретение велосипеда.. 
представь, все приходяшие параметры придётся проверять самому + всю локику пересылки (а у меня одна страница, а всё остальное подгружается через AJAX) + ... + ... + ...




угу.. понравилось то, что нету больше faces-config.xml, а всё осушествляется через анотации..





угу.. вот тут и моя беда.. у меня кое-какие запросы не приходят из JSF, а я их сам изобретаю.. посему стал вопрос, как свои запросы подключить к типа системе JSF, что-бы сразу на лету проверять приходяшие параметры..

кстати, кто проверяет такое:

    @Length(min=5, max=15)
    public String getUsername() { ... }

кто именно следит за этим? можно ли как-то это дело автоматизировать, а не самому проверять анотации?   

 




хм.. а можешь назвать парочку из твоей практики?   

polosatij
Багов icefaces? запросто
до версии 1.5.3 -- невозможно было разместить две таблицы с select'орами (выбор строки) на одной странице.
в текущей (1.5.3):
- На stack panel -- невозможно работать с checkbox (обнуляет из при повторном обращении)
- В calendar -- невозможно отключить partialSubmit (это, кажется, есть и у некоторых других компонент) -- сам календарь кстати очень убогий по функциональности и есть проблемы с отображением в IE6
- Неправильно вычисляется ширина табулятора (TabSet), часто он шире своего контента (правда, это несложно пофиксить самостоятельно)
- Ширина колонок header'а таблицы плохо коррелируется с шириной собственно колонок (это связано с тем, что компонента для заголовка и собственно таблицы генерит почему то две разные таблицы) -- из-за чего таблица некрасиво разлазится
- заявленная поддержка concurrentDOMViews -- не работает
- динамические инклюды работают только после танцев с бубном, описанном на их форуме, я так и не смог заставить их работать безглючно
- есть еще и не мало, навскидку трудно вспомнить..
А если начинаешь пользоваться более серьезно, то сталкиваешся с другими сложностями.
Например, при попытке написать и подключить свой конвертер дат к их календарю -- конвертер не отрабатывает. Молча, без всяких сообщений. Debug исходников показывает такой код: 

То есть, если твой конвертер не реализует IDateConverter то он втихую конвертит своими силами, а IDateConverter это inner интерфейс, нигде не задокументированный, объявленный тут же внутри класса рендерера. Такая вот архитектура.
То есть проект в целом сыроватый и для быстрой разработки не очень подходит, приходится по ходу дела разбираться с их кодом, кое-что править, на другое изобретать различные workaround'ы..
Но, что удивительно, на данный момент лучшей альтернативый я не нашел.. 

Ну, до приходящих параметров я не детализировался. Я имел ввиду, только то что Вам придется внедрять вызовы Ajax Javascript по соответствующим JavaScript событиям для HTML элементов в случае JSP, и для JSF элементов в случае JSF, методика таже самая.