>> Java applets are heavy in use of client RAM,
>> network download is a problem,
>
>Not with JDK1.3.
That will be great the day we can deploy JDK 1.3 clients.
>> browser compatibility is a headache,
>
>Use the plugin.
We use the plugin almost always when we deploy Java applets.
But there is a problem: you can use the plugin for JDK 1.1 or the plugin for
JDK 1.2
It is not possible to install both plugin versions in the same client
workstation.
And they are not compatible. So if project A uses plugin 1.1 and deploys in
the client
workstation and then project B using plugin 1.2 wants to deploy in the same
client workstation... you can imagine the rest.
>> client installation raises doubts about
>> being real thin clients,
>
>Do you count caching of applets as client installation? Isn't this
>basically what the W2K installer does?
I mean when the application is not trivial some form of client
preinstallation is necessary
and then all the client configuration management problems apply, so an
automated
mechanism is convinient, be it CAB files, PVCj, Castanet or Win2K Installer
>> and then any Java programmer can put business rules
>> in his/her applet code.
>
>With the emphasis on *can*. The more powerful tool you use, the more
>possibilities to screw up. No surprise there.
Agreed.
>> HTML 4.0 clients look good because RAM use is what the browser will use
>> anyway, and DHTML, HTML Data Binding, XML, RDS etc provide
>> lots of functionality and user interactivity. Of course the programmer
can
>> abuse this power and put business rules in the client, but then it is a
>> question of good SW engineering to avoid it.
>
>As above then?
The very same, as a programmer I like the power and the responsibility not
to make mistakes.
>> Conclusion: IMHO a good SW developer can develop usable clients
>> with DHTML/RDS/etc if the user can standardize on IE4/5.
>
>And if you cannot? (I.e. internet scenario)
Internet scenario == HTML 3.2 on the client+JSP[+EJB] on the server,
but then this scenario usually does not require complex GUI functionality
so HTML 3.2 is adequate. Internet certainly means not use Java applets,
because:
+ the plugin cannot be expected to be deployed at everybody's home
+ client preinstallation is not practical
+ startup time is critical or else the Internet user will go browse
somewhere else
+ modem speed, wild platform disparity, etc
>> The same SW engineer will face a lot of problems
>> with JDK 1.1 clients because of RAM use and download times.
>
>Why do you compare the latest IE with old Java? The plugin is available
>for use now.
We have deployed lots of Java applets in the last 3 years, using
Navigator/IExplorer/plugin and we have fought against lots of problems.
In one case we found our client's 32 MB PCs could not handle
the load of a full Java applet ORB-enabled and had to do an emergency -- and
I may say,
rather painful migration into a DHTML client that worked fine and saved the
project.
Since then we are looking very hard into DHTML clients.
Our rule now is: If we can do it with DHTML, we do not use Java.
But of course we are doing lots of Swing clients today, because HTML 4.0
cannot do all -- yet.
>> Of course some functionality just cannot be done with HTML 4.0
>> but if it can be done, we want to do it. MicroSoft is doing a
>> great job expanding the limits of what HTML clients can do
>> -- guess why? ;-)
>
>Let me guess: because they do what they always do, and try to force
>everyone to use IE5?
Correct!
Well, I'd love to keep using Navigator, but first it must support HTML 4.0,
DOM, CSS, XML/XSLT. Today's Navigator is very unsatisfactory. HTML code
written with HomeSite 4 will not display correctly in Navigator 4.x, will
display ok
in IExplorer 4/5, so we use IExplorer.
>> BTW in my experience there is little risk of business-rule violations
>> because of DHTML browser incompatiblities.
>"Little risk"? I'd like zero risk, thank you very much.
I think it is zero risk, but being a SW engineer I hate absolute assertions
;-)
>> The client either
>> works fine or does not work at all. It is possible to check USER_AGENT
>> headers at the server or use several client side tricks to work around
>> incompatiblities.
>
>Why use tricks? They take an enourmous amount of time to come up with,
>and you have to keep adding them as time goes.
It's a pain for sure. Life is hard.
And then Navigator 5 will NOT be compatible with JavaScript code written for
Navigator 4.x !
>> It's a shame Navigator is so behind in implementing W3C standards
>> so that we must rely on IE4/5.
>
>I beg to differ on the "must" thing, but a new Navigator version would
>be nice, yes.
We want HTML 4.0, CSS, DOM, XML/XSLT. So we must use IExplorer 4/5.
We expect Navigator 5 to be available a few months after Win2K release
(that's a joke -- ok, not funny ;-)
BTW, this thread is not about dropping J2EE and switching to the full NT
server
package, including IIS, ASP, MTS etc. The idea is J2EE is very much silent
on the
HTML client side, while MicroSoft is doing a fine job in this area.
We are using IE5 on the client but JSP+NES+JRun+Oracle+HP-UX on the server.
Best regards
Javier Borrajo
www.tid.es
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
