Pros & Cons of JSF/Ajax

[Steve]

I need to build a very dynamic client and would be interested in knowing the pros and
cons of using JSF and Ajax to accomplish this.

Thanks.

Steve

 

[Roedy Green]

I need to build a very dynamic client and would be interested in knowing the pros and
cons of using JSF and Ajax to accomplish this.

The biggest problem with Ajax is you have a different JavaScript
implementation in every browser with different bugs and different
proprietary extensions. You also are then limited to browsers with
JavaScript.

JSF on the other hand is not going to be able to pull off clever
client side tricks like keystroke editing.

If you have a captive audience all using the same browser and version,
Ajax looks better. If you have the general public as your audience
then JSF looks better.

Obviously there are many other factors to consider.

 

[Steve]

Roedy,

Thank you for your reply.

I am considering replacing a Java applet and have concerns that JSF and Ajax may not be adequate.

Some of the things the applet does is dynamically populate trees, tables, tabs, panes, comboBoxes, etc., on a page based on user
selections on the same page. The applet communicates with the server to get the required data when the information is not available
at the client. It also presents multiple pages to the user (e.g., JFrames) where info on one page is based upon user selections on
one or more other pages.

Besides keystroke editing, are there other things I will not be able to do with JSF? In particular, do the above sound doable or
might I have some problems?

Thanks for any feedback.

Steve
--

 

[Timo Stamm]

I am considering replacing a Java applet and have concerns that JSF
and Ajax may not be adequate.

Some of the things the applet does is dynamically populate trees,
tables, tabs, panes, comboBoxes, etc., on a page based on user
selections on the same page. The applet communicates with the
server to get the required data when the information is not available
at the client. It also presents multiple pages to the user (e.g.,
JFrames) where info on one page is based upon user selections on
one or more other pages.

Besides keystroke editing, are there other things I will not be able
to do with JSF?

Do you know what problems JSF and Ajax solve?


Browsers forget the GUI state with each page reload. But they reload the
entire page every time you click a link submit a form. This leads to
annoying delays, and makes it very difficult to maintain the UI state of
complex pages.

JSF is a component-oriented UI framework for the serverside. It takes
care of the UI state, and a reliable language and environment is
available to manipute data.

Using AJAX, you can send a request without reloading the whole page, and
just replace the changed elements [1]. This eliminates the delays, and
can preserve the UI state completely.


It should be possible to provide the functionality you have outlined
with a server side framework in combination with AJAX. But do you have
to use JSF?

In a recent interview [2], Jacob Hookom replied to the question "Do you
support Ajax natively?":

| For AJAX, we’re planning on pursuing an extension to JSF 1.2 called
| Avatar, based on various EG members’ ideas that will allow any and all
| parts of JSF to be used in AJAX applications. [...]
|
| The next revision of JSF (2.0) will probably include a case for a
| “Partial Faces Request†(AJAX). Also, there will probably be more use
| of annotations to ease the component development aspect of the spec.

In plain language: JSF has *no* support for AJAX right now.

I would definitely not try to build an AJAX app using JSF. You might
want to read the answers of other developers representing other java web
frameworks. I found them very interesting.


The best java web framework with AJAX support might be Wicket. Have a
look at the website [3] and ask for the current state of AJAX support on
the mailing list [4]. AFAIK, there already is Dojo and Scriptaculous
support.


Timo

_______

1: Some people misunderstand AJAX as writing the complete application in
Javascript. This is possible, but it has some major drawbacks. The
Javascript implementations are equal, but the DOM implementations are
not. I am not the only one with this opinion:
http://www.loudthinking.com/arc/000428.html

2: http://www.virtuas.com/files/JavaWebFrameworkSweetSpots.pdf

3: http://wicket.sourceforge.net/

4: http://lists.sourceforge.net/lists/listinfo/wicket-user

 

[Roedy Green]

Besides keystroke editing, are there other things I will not be able to do with JSF? In particular, do the above sound doable or
might I have some problems?

Vanilla HTML does not have much in the way of smarts. the Form and
table is about as clever at is gets.

You might also consider JAWS. see
http://mindprod.com/jgloss/javawebstart.html

What the disadvantages of signed Applet for you?

 

[Steve]

Thanks for your comments.

I constructed a prototype using a signed applet but my customer is concerned about deploying JREs to all the client workstations.
They suggested JSF as a possible alternative but I am concerned about using a server-side solution when a highly dynamic client is
needed.

Steve

--

I am considering replacing a Java applet and have concerns that JSF and Ajax may not be adequate.

Some of the things the applet does is dynamically populate trees, tables, tabs, panes, comboBoxes, etc., on a page based on user
selections on the same page. The applet communicates with the server to get the required data when the information is not
available
at the client. It also presents multiple pages to the user (e.g., JFrames) where info on one page is based upon user selections
on
one or more other pages.

Besides keystroke editing, are there other things I will not be able to do with JSF?

Do you know what problems JSF and Ajax solve?


Browsers forget the GUI state with each page reload. But they reload the entire page every time you click a link submit a form.
This leads to annoying delays, and makes it very difficult to maintain the UI state of complex pages.

JSF is a component-oriented UI framework for the serverside. It takes care of the UI state, and a reliable language and
environment is available to manipute data.

Using AJAX, you can send a request without reloading the whole page, and just replace the changed elements [1]. This eliminates
the delays, and can preserve the UI state completely.


It should be possible to provide the functionality you have outlined with a server side framework in combination with AJAX. But do
you have to use JSF?

In a recent interview [2], Jacob Hookom replied to the question "Do you support Ajax natively?":

| For AJAX, we're planning on pursuing an extension to JSF 1.2 called
| Avatar, based on various EG members' ideas that will allow any and all
| parts of JSF to be used in AJAX applications. [...]
|
| The next revision of JSF (2.0) will probably include a case for a
| "Partial Faces Request" (AJAX). Also, there will probably be more use
| of annotations to ease the component development aspect of the spec.

In plain language: JSF has *no* support for AJAX right now.

I would definitely not try to build an AJAX app using JSF. You might want to read the answers of other developers representing
other java web frameworks. I found them very interesting.


The best java web framework with AJAX support might be Wicket. Have a look at the website [3] and ask for the current state of
AJAX support on the mailing list [4]. AFAIK, there already is Dojo and Scriptaculous support.


Timo

_______

1: Some people misunderstand AJAX as writing the complete application in
Javascript. This is possible, but it has some major drawbacks. The
Javascript implementations are equal, but the DOM implementations are
not. I am not the only one with this opinion:
http://www.loudthinking.com/arc/000428.html

2: http://www.virtuas.com/files/JavaWebFrameworkSweetSpots.pdf

3: http://wicket.sourceforge.net/

4: http://lists.sourceforge.net/lists/listinfo/wicket-user

 

[Steve]

Thanks for your comments.

My customer has concerns about deploying JREs to all the client workstations and the maintenance involved. They have asked about
alternatives and suggested JSF with Ajax as a possibility. The environment is currently Tomcat (with JSPs), Spring, Hibernate, etc.

Steve

BTW, The prototype I showed them is a signed applet.

 

[Roedy Green]

My customer has concerns about deploying JREs to all the client workstations and the maintenance involved

That is really no different that installing any other program. The
main problem is when talking to the public who may not be permitted to
install any program in a corporate environment or who may have been
lied to that Applets are dangerous.

 

[Chris]

I need to build a very dynamic client and would be interested in knowing
the pros and
cons of using JSF and Ajax to accomplish this.

I've got the same issue. My guess is that the best approach is to buy a
pre-built Ajax framework and use that. That way somebody else has the
headache of dealing with cross-browser issues, bugs, flaky Javascript, etc.
This doesn't eliminate the other downsides of Ajax, which include making it
difficult for search engines to index your pages and losing the "back"
button, but that may not be a problem for you.

The question remains: which pre-built framework to use? I do not know which
ones work well and aren't outrageously expensive.

 

[Tomislav]

Thanks for your comments.

I constructed a prototype using a signed applet but my customer is concerned about deploying JREs to all the client workstations.
They suggested JSF as a possible alternative but I am concerned about using a server-side solution when a highly dynamic client is
needed.

I suggest you consider building a regular swing app and deploy it via Java Web
Start. You can configure it so that it works completely in-memory, so the only
thing you need is a JRE on every client. One click and a full swing rich
client - with all it's flexibility and responsiveness, as well as all the IDE
support for building one - starts up and clients just use it.
I'd say this approach has a number of advantages over AJAX-based solutions,
especially in terms of ease of development, reliability and flexibility. AJAX
development might be going in the right direction, but it's still a long way
away from everyone's favourite tool for highly interactive web apps...in my
opinion, anyway.

t.n.a.

 

[Arvind]

Have you tried RICO ? (http://openrico.org/)

AJAX takes you as far as you'd want to go without a page reload - but
the grunt work of server side, business logic, persistence etc still
remains to be addressed - JSF or AJAX does not change that a single
bit.