This package contains the upload policies: they give you hook entry points, to override the default applet behaviour with a minimum of java code.
This pages describes how to create a new upload policy, to adapt the applet to your needs, without interfering with the core applet, that is: with having compatibility with future JUpload versions. Here are other links on this subject:You'll find on this page a description of the {@link wjhk.jupload2.policies.UploadPolicy} methods, grouped by categories.
Note: Creating a new upload policy is mandatory, if you want to manage some other kind of {@link wjhk.jupload2.filedata.FileData}. You can then add some kind of 'before upload check', or have a specific applet behaviour, for instance be able to hear sound file before upload.
To create a new upload policy, you need to create a new java class: the easiest way is to inherit from @link wjhk.jupload2.policies.DefaultUploadPolicy}. You can then override methods of the UploadPolicy interface that you need to update for your needs.
This kind of customization will be compatible within next JUpload applet release. If you need other hooks (method within the UploadPolicy interface, to allow other customizations), please let me know by posting a message on the sourceforge jupload forums (open discussions for instance), or post a new Feature Request in the jupload sourceforge project page. For instance, some attributes and methods from DefaultUploadPolicy are protected (not private), so that you can use them in your own upload policies.
Here is a sample description of the customization that you can do by using the creating a new policy, using the UploadPolicy interface. All methods are described in the next section of this page.
The JuploadApplet asks the UploadPolicyFactory to create (instanciate) the needed UploadPolicy. That is:
To create a new UploadPolicy, you'll need to:
This methods creates a new {@link wjhk.jupload2.filedata.FileData} object. It returns null is no file data was created, for instance
if this file didn't check some specific validation checks.
Note: use this method to use any FileData specific to your needs. See {@link wjhk.jupload2.policies.PictureUploadPolicy} for a sample
of this.
Specific reaction of the applet, when file are dropped onto it.
Allows the applet to change the way the top part of the applet is displayed, that is: the place where the Choose, remove, remove all buttons are. If you override this method, you must use the given button if you want these functionalities to work. If you don't put the browse button, for instance, the user won't be able to display a file chooser, unless you manage it yourself. See {@link wjhk.jupload2.policies.PictureUploadPolicy}, for a way to use the standard buttons, and add specific ones.
Extension of the createTopPanel() idea. You can place any component of JUpload at any place ... or at no place. If you override this method, you'll have to call the {@link wjhk.jupload2.gui.JUploadPanel} getter to get core applet objects. These are:
You probably won't have to override this method. Note that this method allows you to not display the stop and upload buttons.
This method should not be used any more. Use the showStatusBar applet parameter instead.
Reaction of the applet, when a file is selected in the file list. For instance, {@link wjhk.jupload2.policies.PictureUploadPolicy} displays the selected picture in the preview component.
Reaction of the applet, when a file is double clicked. For instance, {@link wjhk.jupload2.policies.PictureUploadPolicy} opens a dialog box, that contain a full screen display of the current picture.
Allows the applet to change user another JFileChooser. Your specific file chooser should inherit from JUploadFileChooser
Called by the {@link wjhk.jupload2.gui.JUploadFileFilter}. This method contains the actual response to the { @link java.io.FileFilter#accept(File)} method of the FileFilter interface. It allows to control what can be displayed on the file chooser.
The file filter description, in the file chooser. The default is to display the list of authorized extensions. This can be too large, if many extensions are authorized. You can then put here a more descriptive text.
Returns the icon that must be displayed for this file on the file chooser. This method is called asynchroneously, so that long calculation won't block the applet. See an example in the {@link wjhk.jupload2.policies.PictureUploadPolicy}. This policy returns an icon created from the picture content.
Allows a control of the current upload policy, before any upload work starts. You'll probably have to override this method if you want to do pre-upload checks on files
This method is called just before upload, for instance to allow any 'before upload' work, like computing some global information. See also the FileData.beforeUpload(), that is called for each file.
You probably won't have to override this method, if you use the stringUploadSuccess and stringUploadError applet parameters. If not, this method allows you to check that upload is a success. That is: there is no error (for instance, page not found), and the server side application actually accepted the file(s).
Allows the caller to free any resource used during upload. See also the FileData.afterUpload(), that is called for each file.
This method is useful only in HTTP upload (not FTP, for instance). It allows any check or update of applet variables based on the server return. You probably should not have to override this method.
This method is useful only in HTTP upload (not FTP, for instance). It returns the full HTTP response, with headers. It allows any check or update of applet variables based on the server return. You probably should not have to override this method.
Add a header to the list of all header that must be added to all upload. Useful only when uploading in HTTP mode. If you override this method, you'll have to override the onAppendHeader(ByteArrayEncoder) method.
Add header on the HTTP request, while this requet is being written to the server. If you override this method, you'll have to call super.onAppendHeader(ByteArrayEncoder) method.
Allows the upload policy to add specific headers. This is used only for HTTP upload.
Load data from an HTML form. These data will be set with each file in the upload. See also the {@link wjhk.jupload2.filedata.FileData#appendFileProperties(ByteArrayEncoder)} method, for a way to add data specific to one file.
The last category of methods is the getters and setters. There is a getter for each applet parameter. Most of applet parameters also has a setter. You can override them to add some execution time calculation. For instance, {@link Coppermine#getPostURL()} calls the default getter, than the album id as a new parameter on the URL.
Here are the other getters:
Allows to set any property. This can be called for any applet parameter. This method can be called from Javascript, to allow runtime control of applet state by the javascript.
This important getter returns the JUploadApplet. From it, you can get any GUI component.
Returns the current date format, so that all date/time are displayed by using the same format.
For SSL management. Standard code should be good enough.
You should override this method, to display any parameter specific to your upload policy. See {@link wjhk.jupload2.policies.PictureUploadPolicy} for a sample.
You probably won't have to override this method. Displays an alert box, based on the key of the translated message.
You probably won't have to override this method. Displays an alert box.
You probably won't have to override this method.. Will be renamed, as it just logged an info message.
You probably won't have to override this method. Will be renamed, as it just logs a warning.
You probably won't have to override this method.. Will be renamed, as it just logs a debug message.
You probably won't have to override this method. Will be renamed.
You probably won't have to override this method. Will be renamed.
You probably won't have to override this method. Will be renamed.
You probably won't have to override this method. Manages text translation.
You can change the applet wait cursor, by overriding this method.
I don't think you'll have to override this one...
send the debug output to the urlToSendErrorTo applet parameter. Allows logging on the server ... if this calls succeed, which is not the case when the server has a big trouble.