Tech Notes
Tech Notes |
Client Interface Options
Question
What are my options for making client interfaces?Answer
HTML only
This is your most portable answer. It will work on any operating system with any web browser. You will have to decide whether you want to use frames, or tables, or other techniques that may not be supported across all browsers.
What the interface looks like is limited by the rules of HTML and what your graphic team can conjure up. There can be tremendous variety. Some companies have decided to make their applications look as much like a Windows app as possible, others have not.
We do not recommend that people have, as a goal, a 1-to-1 mapping of "my Delphi app" to "my web app" because that generally doesn't succeed in a multiuser web context. It is better to take one step back twenty years to a CICS-style interface, where there is a clear flow back and forth between the client and the server, with smaller, more frequent screens. (These rules need to be modified for Intranets with high bandwidth, of course.) Then take a step twenty web-years forward and realize that the "server" is really a distributed computing environment, consisting of one or more machines, one or more web servers, one or more databases or even types of databases, and one or more middleware modules. It is the middleware that you write in WebHub, and what it does, fundamentally, is take input from the client, apply some processing rules, and send back output in the form of HTML, JavaScript, or Java applet parameters.
HTML plus JavaScript
This is a pretty good answer, because using JavaScript you can add some important features like quicker required-field checking and certain special effects (like mouseover). The problem is that there is a war between Netscape and Microsoft, and therefore many differences in feature capabilities and bugs between browser versions. If you know that 90% of your users are likely to have "a current browser" then this is worth pursuing.
HTML plus Java Applets
This is an option for people who must have Java for one reason or another. An excellent example of this was the OrderGenie site in New Zealand, which was built using WebHub purely for middleware and Java for the front end. The result, for them, was no dependence on JDBC and a fully-feature client application. Their user base is not public, it is repeat customers, so the overhead of a Java application was not a problem.
Which answer for you?
The decision depends on what clients you have to support, how quickly you need to deliver your solution, what skills your team has, what your budget is...
Running DynHelp.exe v1.2.0.6 on WebHub-v2.125 built by D14
Calc time: 109 ms

