Swing vs. Web vs. ...

[Wim Lambrecht]

Hi,
(sorry if i'm not in the correct forum)
During analysis & design you usually - for most of the applications - know quite fast which technologies you want to use (a web-interface or a client-app AND the underlying tek 'Swing', 'struts', ...). But sometimes it's not so obvious.
What i really like to have is some list of criteria or a checklist which i can use to check against my desired application requirements. And which guides me to the correct technology.
A appreciate any help.
thanks in advance !Wil

[Vinod John]

Below are few things that could help you decide ...
When to uses Swing/JFC based frontend
1) When the client should be flexible and interactive.
2) If you want to reduce network traffic because you can add some validation functionality at the client side.
3) If is a intranet application, you don't need to impress your employee.
When not to uses Swing/JFC based frontend
1) If it is an intranet aplication (because if you are using Rmi as a transport protocol you may have to sacrifice son security)
2) If you are sure the client may access this aplication over slow network.
3) If distributing the client is a problem. (you can use a Applet client to solve this problem)
When to uses html based frontend
1) If you know the client will be accessing the app from a slow network.
2) If you wan the frontend to have lot of attraction in addition to functionality.
In addition you can also use a xml/xslt/html based front end, when you want to brand your front end according tothe customer or your client is a mobile equipment. But this is very resource intensive process.
Mostly companies uses Swing base front end, when it is accessed internally (like a app used by the call center only) that way the importance is more on productivity.
When you opt for a HTML based front end using jsp/servlet, it is generally better to use a page navigation frame-work like struts as it would reduce a work load and the development time.
[ June 26, 2003: Message edited by: Vinod John ]

[Wim Lambrecht]

Hi John,
Thanks for your quick answer (sorry for my slow reply).
Maybe you can help me with some additional questions (in bold), or point me to some resources. Again, Thanks in advance :

Originally posted by Vinod John:
Below are few things that could help you decide ...
When to uses Swing/JFC based frontend
1) When the client should be flexible and interactive. <- Are the current Web-technologies not flexible and interactive enough ? They claim to be.
2) If you want to reduce network traffic because you can add some validation functionality at the client side. <- do you know of any mechanisms to cache some data on the browser-side. I like to use it for large lists (not only read-only).
3) If is a intranet application, you don't need to impress your employee.
When not to uses Swing/JFC based frontend
1) If it is an intranet aplication (because if you are using Rmi as a transport protocol you may have to sacrifice son security) see "Java WebStart" below + my domein stuff (business rules etc) are implemented as EJB running on some Application Server. My client-app should talk to some Session-Bean.
2) If you are sure the client may access this aplication over slow network. <- but large lists will also slow down my application, because of the no-caching on the browser-client. Are the alternatives ?
3) If distributing the client is a problem. (you can use a Applet client to solve this problem) <- Maybe i can use Java WebStart (with a Swing-client app) for this, or are there some disadvantages you know off ?
When to uses html based frontend
1) If you know the client will be accessing the app from a slow network. <- but large lists will also slow down my application, because of the no-caching on the browser-client. Are the alternatives ?
2) If you wan the frontend to have lot of attraction in addition to functionality.
In addition you can also use a xml/xslt/html based front end, when you want to brand your front end according tothe customer or your client is a mobile equipment. But this is very resource intensive process.
Mostly companies uses Swing base front end, when it is accessed internally (like a app used by the call center only) that way the importance is more on productivity.
When you opt for a HTML based front end using jsp/servlet, it is generally better to use a page navigation frame-work like struts as it would reduce a work load and the development time.
[ June 26, 2003: Message edited by: Vinod John ]

If 'easy access' and 'availability' are desired issues, isn't a web-UI the best choice or can Swing&JavaWebStart compete with that.
Another issue is, that the webapp possibly needs to access the local disk. How is that done.

[Vinod John]

Originally posted by Wim Lambrecht:

If 'easy access' and 'availability' are desired issues, isn't a web-UI the best choice or can Swing&JavaWebStart compete with that.
[/b]

Of course html based UI (note web based UI can also be Applet or ActiveX based ones) are easy to access compared to others. As the other thick clinent web based UI, takes some time to get initialized. when accessing from a slow network it will not be desirable.
Availibility of a application generally depends on the fail over mechanism you employ. It is not related to client.

Originally posted by Wim Lambrecht:

[qb]
Another issue is, that the webapp possibly needs to access the local disk. How is that done.

When using applet this will be a problem you will have perform extra work like signing the applet. A html based front end and also a Swing based Application doesn't have this problem.
If your app is going to be accessed on the internet and you want it to access the local maching the uses java/JSP/Servlet/html/Javascript for the presentation layer.
[ June 30, 2003: Message edited by: Vinod John ]

[Bear Bibeault]

If your app is going to be accessed on the internet and you want it to access the local maching the uses java/JSP/Servlet/html/Javascript for the presentation layer.

If by 'local maching' [sic] you mean the client system, this is incorrect. A web app based upon these technologies has no ability to access the client file system.
bear
[ June 30, 2003: Message edited by: Bear Bibeault ]

[Vinod John]

Originally posted by Bear Bibeault:

If by 'local maching' [sic] you mean the client system, this is incorrect. A web app based upon these technologies has no ability to access the client file system.
bear
[ June 30, 2003: Message edited by: Bear Bibeault ]

Yes you are right the application running on the server can't access client (as in most cases it won't be knowing the IP address of the client), but what I meant is the client, the html or the applet or the swing based application, can actually access the client machine (in case of html base front end you can use java script/vb script to do that or you sign a applet and give it special previlages).
Think I clarified my statement.

[Bear Bibeault]

in case of html base front end you can use java script

Client-side Javascript has no access to the client file system.
bear

[Tim Holloway]

$0.01US - HTML will be more portable, but applets can have more flexible and more intelligent UIs. I especially like Swing tables (warts and all) over HTML tables full of HTML controls.
$0.01US - Try to keep files off the client machine wherever possible. They're easier to back up and to secure when they're on the server and you don't need signed applets to access the data
Just my 2 cents.

[Vinod John]

Originally posted by Bear Bibeault:

Client-side Javascript has no access to the client file system.
bear

Correct me if I am wrong, I was always of the impression that you can use javascript, with netscape libraries and/or by signing it, to do most of the things you do with a signed applet this will also include accessing the client file system.

[Rohit Ahuja]

Tim Dear,
Even i favour swing over HTML, but was just wondering whether Internet Explorer or Netscape Navigator favour swing...