> OK, fine - it may not fit your definition of "thin" (I'll
> give mine later,
> which are just as 'valid' (or not :) ) as yours), but IMO,
> and HTML front
> end does not come even close to fitting the definition of
> RAD, which for me
> would be much more important.
RAD, like thin, has many definitions. For mine (which may or may not
qualify as yours), if a customer comes in and says, I would like you to use
"ZYX" font which is standard in out 100K person organisation, for HTML, it
is just a simple matter of adding a line, <basefont>. If different clients
wants different fields to display, just change the HTML - no need to touch
that EXE, redesign forms, recompile code, install new exe, etc. Now that
*IS* RAD!
Better still, have an HTML specialist design you web pages, and have a
programmer do the program. I have seem many applications that work fine,
but have very poor UI - classic case of one designed by programmers. Its
hard to find good programmers who are also good UI designers, and vice
versa, so why not separate the two. HTML makes this very easy. If you want
to change the look and feel, get another HTML designer to do the job.
Then, there is always Java applets ...
> Here's my current ideas of "thin"
> 1. Browser based (thin but with no RAD, not if you want it to
> look good) OR
How many EXE based applications *look* better than well designed web sites?
> 2. EXE - single .exe, maybe a few unregistered DLL's,
> packaged up in a way
> that the user doesn't need to do anything to install/update -
> ie, a .cab,
> NOT an installshield install (bloatware to install bloatware).
Still requires an install ... and the associated problems with compatibility
with client machines. Think for a moment that a $10 each cost of
installation per workstation on a 1000 client system will cost $10000! ...
then you release a new version! For browser based applications, leave the
cost of installing the browser up to the hardware vendor - ie., you buy a
computer, you expect to have an OS and a browser installed at the very
least. Nothing else to install.
> 3. NO DB libraries on the client. PERIOD.
> MIDAS/CORBA/DCOM?/HTTP transport.
Definitely agree about the DB library. HTTP transport is usually built into
most modern OS, so it is not an issue. As for the rest, I classify them as
thick - for the installation reason above.
> 4. No setup - this is not as stupid as it sounds, but how
> many apps do YOU
> use (or worse yet, write) that dont have intelligent defaults!!!
Definitely agree on this one. The user does not need to be bombarded with
1001 options before the software can be used.
Regards,
Dennis.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
