|
|
 |
Uploading FAQ
This page covers everything about uploading, from beginner
to advanced.
- How to upload
You must upload all of these files before the applet will work. We recommend that
you keep all of these files in the same directory on the server.
- the .cab file (upload in ascii mode)
- the .jar file (upload in ascii mode)
- the index file
- if this is a .txt or .xml file, upload in ascii mode
- if this is a .zip file, upload in binary mode
- if you selected parameter indices, there is no index file
- any image resources required, such as icons (upload in binary mode)
- the HTML file containing the applet (upload in ascii mode)
Software for uploading: we recommend simple
FTP transfer applications such as WS_FTP from
www.ipswitch.com. These
make it very clear what is going on and are preferable to more
complex and expensive systems.
- How not to upload
- Not uploading all the files
It sounds too obvious, especially for the professional web developer.
But it is probably the number one sin. Remember to upload ALL
the files. Really all of them. If you can't remember how many
there were, look at your delivery email again.
- Not ending up with the same files on the server
This one really happens too. The files on your server just
aren't the ones you got working locally. Check filenames. Check
versions. And look at all the files involved - HTML as well as
applet files.
- Using codebases
If you try using codebases, file management problems frequently result,
because of the added dimension of complexity.
Codebases are usually unnecessary. Keep your applets and the HTML
files they are embedded in in the same directory and you will be
much happier in the long run.
- Uploading to the wrong directory
As servers and server-side programming becomes more complex,
developers are increasingly tempted to think they have to upload
applets to special directories to get them to work. However applets run
client-side, which means that to the server they are just a heap of
dead binary. The proper place for an applet is alongside normal
HTML files. In fact, putting an applet in CGI-bins and other exotic
locations can even stop them working.
- Uploading in the wrong mode
CLASS, CAB and JAR files must be uploaded in BINARY mode
(like images). HTML, text and other ascii files (such as
perl, js and other scripting resources) are uploaded in ASCII
mode. Use the wrong mode and your applet won't work.
- Uploading with over-complex software
If you are running version 20 of your $5000 thought-to-code web design
environment, don't necessarily expect it to upload properly. The more
complex the programme, the more that can go wrong and the less likely
you are to see what went wrong. Upload files with the simplest, cheapest software
available. Try Cute FTP or WS FTP.
- Not observing resource relationships
If the applet reads in a resource it requires to run (such as an
icon image or an index file), this resource must either be in the
same directory as the applet, or a sub-directory of the applet's
directory. This does not apply to hyperlinks triggered by the applet,
only to resources used within the applet.
- Writing paths into the code tag
<APPLET CODE="http://[mySite]/myApplet.class"> or
<APPLET CODE="../../myApplet.class">
will never work, however much you try.
- Getting confused by browser cache
You uploaded OK, but you can't see the new results. Keep the
SHIFT and CTRL keys pressed with your free hand while you
click on the browser "refresh" button with the mouse. This
will clear cache and display the most recent results. If this
still doesn't work, close down all your browser windows and try
to clear cache more thoroughly.
- Getting confused by development studio cache
You can see the changes in your $5000 thought-to-code web design
environment, but when you click the magic "publish" button, the
changes aren't on your server - and perhaps even the applet isn't
there. Well, does the $5000 thought-to-code web design
environment publish (upload) what it displays, or what you have
clicked five further buttons to save and reserve for publication?
And has it realised that it should upload more than just the HTML
file?
- Getting uppercase names confused
Your server may be case-sensitive. Try to keep everything
lowercase - this is the most reliable strategy. And watch
out for other characters in filenames and directory names which
your server may not agree with. Try to stick just with lowercase
letters and numbers, avoiding spaces, punctuation marks and special
characters.
- Uploading to unlicenced locations
This happens increasingly on large projects where the
liaison between purchase authorisation and sub-project
implementation is not close. Release applets are licenced
and locked to specific network locations. They are designed
not to work unless they are placed at a licenced location.
- Forgetting to add your keys
Keys are required to unlock the software for the networked
locations it is licenced for. If the software works before
uploading but not afterwards, it may also be because you skipped
reading the delivery email and didn't add the keys (or didn't
add them to the online version of the HTML file).
- Incorrect permissions on a UNIX server
By default the permissions should be set correctly. However
if you have played with your server defaults, you may have
problems. The "other-read" permission must be available. For
example, CHMOD 644 is good. And remember that as the applet
runs client-side, not on the server, permissions must be
set correspondingly on any resources the applet tries to access.
- Mime type not supported by server
Respectable and well-configured servers will always be configured
to allow the delivery of CAB and JAR files. However in some cases
a server administrator may have forgotten to implement the type.
Contact your server administrator if you find that the CAB and JAR
files are uploaded but not being delivered.
| | |
superior performance
