* Here is the list of all parameters available in the current package, that is: * available in available upload policies. These are applet parameters that can * be 'given' to the applet, with tags, as explained below in the example. *
** Let's start with some hints:
| Parameter name | *Default value / * Implemented in |
* Description | *
|---|---|---|
| afterUploadTarget * Since 2.9.2rc4 |
* _self * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter allows to select a specific target frame when redirecting
* to afterUploadURL. The following values are possible:*
|
*
| afterUploadURL | *null * since 2.9.0 * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter is used by all policies. It allows the applet to change
* the current page to another one after a successful upload. * This allows, for instance, to display a page containing the file description * of the newly uploaded page. Since version 3.0.2b2, you can specify a * JavaScript expression instead of a plain URL. So afterUploadURL can now * contain: *
* "javascript:alert('Thanks for the upload');", then after a
* successful upload, a messagebox would pop up. Since 3.0.2b3 there are now
* three place holders available which can be used as parameters in function
* calls:
*
"javascript:alert('%body%');",
* then the resulting message box will show the body content of the last server
* response. |
*
| albumId | *-1 * * {@link wjhk.jupload2.policies.CoppermineUploadPolicy} |
* This parameter is only used by CoppermineUploadPolicy. So it is to be
* used to upload into a coppermine
* picture gallery. This parameter contains the identifier of the album,
* where pictures should be used. See CoppermineUploadPolicy for an example. * Before upload, CoppermineUploadPolicy. * {@link wjhk.jupload2.policies.CoppermineUploadPolicy#beforeUpload()} checks * that the albumId is correct, that is: >=1. |
*
| allowedFileExtensions | *empty string * since 2.9.0 * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter allows the caller to specify a list of file extension. If
* this parameter is specified, only file with this extension can be selected in
* the applet. * This parameter must contains a list of extensions, in lower case, separated * by slashes. eg: jpg/jpeg/gif |
*
| allowHttpPersistent | *false * since 3.0.0rc1 * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter allows to switch off persistent HTTP connections which are
* enabled by default (and the protocol version allows it). Currently, we
* encountered problems with persistent connections when testing on a windows
* box using a loopback interface only. * Note: default value changed to false in 4.0 version. |
*
| browsingDirectory | *null * since 4.0.0b2 * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter allows to control the starting browsing directory, that
* is, the directory the is the current one when the file chooser is open. * Notes:
|
*
| debugLevel | *0 * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* With 0, you get the normal production output. The higher the number is,
* the more information is displayed in the log window. Here are some hints
* about debug level values (please note that this is indicative ... including
* for me, as I'me writing this during 3.3.2 release: * Note: All debug messages are stored in a temporary log file. This can be used * to display more information, if needed. See also the urlToSendErrorTo * applet parameter. |
*
| fileChooserIconFromFileContent | *0 * since 3.1.0b * {@link wjhk.jupload2.policies.UploadPolicy} |
* This parameter allows to control whether the file icons in the file
* chooser are calculated from the file content. This is currently only
* available for pictures. * If activated, the file chooser will open each pictures, and calculate the * icon by resizing the picture. This is done in by using thread of minimam * priority, to minimize performances impact on the navigator. Available values * are: |
*
| fileChooserIconSize | *20 * since 3.1.0b * {@link wjhk.jupload2.policies.UploadPolicy} |
* This parameter allows to control the size of icons, in pixels, in the
* file chooser. Used only when fileChooserIconFromFileContent is activated. * Note: The standard icon size is a value of 20. With 50, you'll get a better * view of the picture. |
*
| fileChooserImagePreview | *true * since 3.1.0b * {@link wjhk.jupload2.policies.PictureUploadPolicy} |
* This parameter allows to control whether an preview is available for * picture in the file chooser. If activated, the file chooser will open the * preview in a separate thread, of high priority. This avoid blocking the * applet while calculating the preview picture, when the user just * double-clicked a picture file. This parameter is ignored for * DefaultUploadPolicy. * |
| fileFilterName | *null * since 5.0.0 |
* Contains the name of the file filter, as it will be displayed in the drop
* down list of filters, in the file chooser. If this name is given to the
* applet, it will be returned by the {@link FileFilter#getDescription()}
* method. * |
* * |
* Since 3.3.0, this parameter is no more used. The full applet upload HTTP
* request to the server is now correctly encoded. * * Example: if the "UTF8" encoding is chosen, the PHP function urldecode can be * used to decode the filename. |
* |
| formdata | *null * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} * Since 2.9.2rc4 |
* With this parameter, the name of a HTML form can be specified. If the
* specified form exists in the same document like the applet, all all
* form-variables are added as POST parameters to the applet's POST request. * Note: Whatever value is in the httpUploadParameterType applet * parameter, these parameters with the name of the given input in the form. * That is: if you have an input text named 'myText', there will be one myText * parameter in the HTTP upload request, with the text/plain mime type, and * whose value is the content of this field, in the form. |
*
| ftpCreateDirectoryStructure | *false * since 4.2.0 * {@link wjhk.jupload2.policies.UploadPolicy} |
* This parameter allows to control whether the directory structure on the
* client side must be created on the server side. * Example: if the user upload the test/ directory, which contains the * readme.txt file. With ftpCreateDirectoryStructure to false (or default * value), the readme.txt is uploaded in the postURL directory. If set to true, * the test/ folder is created as a subfolder of the path given in the postURL * directory, and the readme.txt is uploaded in this subfolder. * Note: in HTTP upload, the pathinfo and relpathinfo allows the server side * script to manage this directory structure. |
*
| ftpTransfertBinary | *true * since 4.1.0 * {@link wjhk.jupload2.policies.UploadPolicy} |
* This parameter allows to control whether the upload should be done in * binary or ascii mode. Default is to upload in binary mode. | *
| ftpTransfertPassive | *true * since 4.1.0 * {@link wjhk.jupload2.policies.UploadPolicy} |
* This parameter allows to control whether the upload should be done in FTP * passive mode, or in active mode (where the FTP server opens a connection to * the client, to do the upload). Default passive mode. | *
| highQualityPreview | *false * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* If this parameter is set to true, the applet will call the
* BufferedImage.getScaledInstance(), instead of doing a basic scale
* transformation. This consume more CPU: on a PII 500MHz, the full screen go
* from around 5 seconds to between 12 and 20 seconds, for a picture created by
* my EOS20D (8,5M pixels). The standard preview (above the file list) seem to
* be displayed at the same speed, whatever is the value of this parameter. * Note: when resizing is done before upload, the * BufferedImage.getScaledInstance() is always called, so that the uploaded * picture is of the best available quality. |
*
| httpUploadParameterName | *File * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} * since 4.5.0 |
* Contains the parameter name, that will be used to send the file in the
* HTTP upload request. The default value (File), associated with the default
* value for httpUploadParameterType (see below), makes all file be uploaded
* with name from File0 to FileN (when there are N+1 file to upload). * Put another value, of your server part script need a particular parameter * name to work properly. * Note: valid characters for this parameter are: first letter (letter or * number), next letters (letter, number or underscore) |
*
| httpUploadParameterType | *iteration * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} * since 4.5.0 |
* Allowed values are: * Note: All parameters common to all pictures are sent directly. For * instance, if toto is given on the URL, the toto parameter is sent as is (no * toto0 for iteration or toto[] for array). Also, if you use the * formdata applet parameter, these parameters are sent as is (no 0 or [] * added to the parameter name). |
*
| keepOriginalFileExtensionForConvertedImages | *false | *is only relevant, if targetPictureFormat is specified. *
|
*
| lang | *Navigator language * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* Should be something like en, fr... Currently only French
* and English are known from the applet. If anyone want to add another language
* ... Please translate the wjhk.jupload2.lang.lang_en, and send it back to
* |
*
| lookAndFeel * since 2.5 |
* empty * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This allows to control the look & feel of the applet. The authorized
* values are:
*
|
*
| maxChunkSize * Since 2.7.1 |
* 0 * Long.MAX_VALUE * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameters defines the maximum size of an upload.
*
* How to build the server part: the server will have to 'guess' that the * file is split, and then it will have to reconstruct the uploaded file. Here * are the necessary informations: *
* If one file is bigger than maxChunkSize, all previous files are * uploaded (at once or not, depending on nbFilesPerRequest). Then the 'big' * file is uploaded alone, split in chunk. Then upload goes on, file by file or * not, depending on nbFilesPerRequest. |
*
| maxFileSize * Since 2.7.1 |
* 0 * Long.MAX_VALUE * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter identify the maximum size that an uploaded file may have.
* It prevent the user to upload too big files. It is especially important when
* chunk upload is activated (see below maxChunkSize).
*
|
*
| maxPicHeight | *Since 3.3.0: Integer.MAX_VALUE * (was -1) * * {@link wjhk.jupload2.policies.PictureUploadPolicy} |
* This parameters allows the HTML page to control the maximum height for
* pictures. If a picture is to be download, and its height is bigger, the
* picture will be resized. The proportion between width and height of the
* resized picture are the same as those of the original picture. If both
* maxPicHeight and maxPicWidth are given, it can happen that the resized
* picture has a height lesser than maxPicHeight, so that width is no more than
* maxPicWidth. * Precisions: * If this parameter value is negative or 0, then no control is done on the * picture height. * If the original picture is smaller than the maximum size, the picture is not * enlarged. * If the picture is resized, its other characteristics are kept (number of * colors, ColorModel...). The picture format is kept, if targetPictureFormat is * empty. If the picture format is a destructive (like jpeg), the maximum * available quality is chosen. * See also maxPicWidth, realMaxPicHeight |
*
| maxPicWidth | *Since 3.3.0: Integer.MAX_VALUE * (was -1) * * {@link wjhk.jupload2.policies.PictureUploadPolicy} |
* Same as maxPicHeight, but for the maximum width of the uploaded picture.
* * See also maxPicHeight, realMaxPicWidth |
*
| nbFilesPerRequest | *1 since 4.3.0 * (was -1) * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This allows the control of the maximal number of files that are uploaded
* in one HTTP upload to the server. * If set to less than 1 (0 or negative), there is no maximum. This means that all files are uploaded in * the same HTTP request. * If set to 5, for instance, and there are 6 files to upload, there will be two * HTTP upload request to the server : 5 files in the first one, and that last * file in a second HTTP request. |
*
| pictureCompressionQuality | *0.8 * since 3.1.0 * {@link wjhk.jupload2.policies.PictureUploadPolicy} |
* This parameter controls the picture compression quality, when writing the
* picture file. 1 means high quality picture, but big files. 0 means poor
* quality pictures, but small files. 0.8 is a good compromise for the web. * It is different from the highQualityPreview, which controls the way picture * are resized in memory. * This parameter is currently applied only to jpg (and jpeg) pictures. |
*
| pictureTransmitMetadata | *false since 3.3.0 * (was true before) * since 3.2.0 * {@link wjhk.jupload2.policies.PictureUploadPolicy} |
* This parameter controls whether the applet transmit metadata of the
* original picture. This may prevent personal information to be thrown on the
* net. * Note 1: This parameter is especially important for picture coming from the * Canon EOS 20D, 30D and 40D: pictures shooted in portrait mode contain * metadata that are incompatible with Java 1.6.0_3! The colors of transformed * pictures become strange... Since 3.3.0: default to false, to avoid * this annonying (and currently not explained) problem. * Note 2: |
*
| postURL | *null since 1.9.2rc4, (was Mandatory before) * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter specifies the target URL toward which the files should be
* uploaded. Since version 1.9.2rc4 this parameter is not mandatory anymore.
* Instead, if omitted or a relative URL is given, the resulting URL is
* constructed from the applet's DocumentBaseURL. This means, that if the applet
* tag is dynamically constructed from a PHP script without specifying
* postURL, the same same script receives the subsequent
* POST request(s). If this URL may change during the applet execution time, you
* can call the setProperty applet method from javascript, or create a new
* UploadPolicy class and either :
*
* Note 2: in FTP, you can't use path that contain spaces. Filename may * contain spaces. Note 5: in HTTP, the applet use the current Java * parameter to connect to the host. By default, this configuration is to use * the navigator configuration. So, if a proxy is configured in the navigator * network configuration, the applet should use it automatically. * Note 3: FTP URL should looks like: * ftp://username:password@myhost.com:21/directory * Note 4: in FTP, you'll have to add the jakarta-commons-oro.jar and * jakarta-commons-net.jar jar files in the applet ARCHIVE tag attribute. See * the 'advanced_js_demo.html page for a sample. You'll have to put the two * files coming from the JUpload distribution in the same directory as the * wjhk.jupload.jar. * Note 5: in FTP, you can use the user default folder by putting no * folder. The URL can be: ftp://user:mdp@host |
* Note 6 (security): take care that the full URL is visible, if the user
* take a look at the page source. So, you should take care when putting login
* and password there.
*
| readCookieFromNavigator | *Since 4.3.0: Boolean * (true) * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} * Since v2.8.1 |
* If true (default), the applet read cookies from the navigator, with the * javascript document.cookie value. If false, the caller should put the * relevant 'Cookie' header in the specificHeaders applet parameter. This allows * to override any javascript cookie access restriction. | *readUserAgentFromNavigator | *Since 4.6.1rc2: Boolean * (true) * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} * |
* If true (default), the applet read the userAgent from the navigator, with * the javascript document.userAgent value. If false, the caller can put the * relevant userAgent header in the specificHeaders applet parameter. | *
| realMaxPicHeight | *Since 3.3.0: Integer.MAX_VALUE * (was -1) * * {@link wjhk.jupload2.policies.PictureUploadPolicy} * Since v2.8.1 |
* This parameters is about the same as maxPicHeight. It overrides it for
* pictures that must be transformed (currentlty only when the picture is
* rotated). * The aim of this parameter, is to prevent the applet to resize picture, and * let the server do it: it will be much quicker. * This allows you to: *
* See also maxPicHeight, realMaxPicWidth, maxChunkSize (to override any * server upload size limitation). |
*
| realMaxPicWidth | *Since 3.3.0: Integer.MAX_VALUE * (was -1) * * {@link wjhk.jupload2.policies.PictureUploadPolicy} * Since v2.8.1 |
* Same as realMaxPicHeight, but for the maximum width of uploaded picture
* that must be transformed. * See also maxPicWidth, realMaxPicHeight |
*
| retryMaxNumberOf | *1 * Since 5.0.0 |
* Maximum number of retries, that the applet will do, for upload resumable
* error. A 'upload resumable error', is typically a network error. The default
* value is 0, to maintain the same behaviour as before. * This maximum of allowed retries is for each packet, that is: if one packet * fails two times, and succeed in the third attempt, the next packet will still * have up to retryMaxNumberOf retries. For instance, the default value (1), * means that the applet will do a one new attempt after a first upload error, * for each packet. |
*
| retryNbSecondsBetween | *30 * Since 5.0.0 |
* The number of seconds, to wait, before trying a new upload of a packet * whose upload was in error. This is used if retryMaxNumberOf is 1 or * more, and if 'resumable upload error' occurs. | *
| serverProtocol | *null since 2.9.2rc4 * (before: "HTTP/1.1") * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter allows the control of the protocol toward the server. It
* can be HTTP/0.9 (not tested), HTTP/1.0, HTTP/1.1 and FTP. HTTP supports
* https. Since version 2.9.2rc4, the default is null, introducing a new
* facility of automatically adjusting the protocol according to the server
* response. * This parameter is really useful only in * {@link wjhk.jupload2.policies.CoppermineUploadPolicy}, as the coppermine * application also controls that the requests send within an HTTP session uses * the same HTTP protocol (as a protection to limit the 'steal' of session * cookies). |
*
| sendMD5Sum | *false * since 5.0.0 * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter indicates whether the applet will send the MD5Sum for * uploaded files, or not. If set to true, the MD5Sum is sent in the * md5sum HTTP POST argument. | *
| showLogWindow * Since 3.0.2 * Changed in 3.5.0 |
* true * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter was formerly known as showStatusBar which now has a
* different purpose. * Since 3.5.0: Available values are (case sensitive): * Until 3.4.2, it works this way: If given with the False value, * the log window will be hidden. The applet will still store all debug * information in it. But the user won't see it any more. If a problem occurs, * the urlToSendErrorTo can still be used to log all available * information. |
*
| showStatusBar | *True * * New meaning since 3.0.2 * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This parameter controls if the status bar is shown in the applet. If * shown, the stausbar provides information about the current transfer speed and * estimated time of completion. Before version 3.0.2, this parameter was used * to control visibility of the log window. This is now controlled by * showLogWindow. | *
| specificHeaders | *null * * Since 3.0.2 * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* Allows the caller to add any header(s) to the applet. These headers will
* be sent with each HTTP request to the server. If you put several lines in
* this parameter, these parameter should be separated by the "\n" string
* (not the LineFeed character, but the antislash character followed by the n
* character, like msg="\\n";). No "\n" at the end: it will be added
* by the applet. In PHP, put '\n', and not "\n" (See PHP doc, on
* strings) * This allows an easy management of Basic HTTP authentication. Just add * a header like this one: * Authorization: Basic Base64EncodedString Where Base64EncodedString is the * string "login:passord" encoded in Base 64. |
*
| sslVerifyCert * Since 3.0.2b1 |
* none * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* With this parameter, the handling of certificates when using SSL can be
* configured. There are 4 possible settings: *
* The location of the local truststore and keystore uses the normal JRE * conventions. This means, that the system truststore is used for verifying * server certs (usually in $JAVA_HOME/lib/security/cacerts) unless either the * system property javax.net.ssl.trusStore specifies another location or * a file .truststore exists in the user's home directory. If the user * decides to permanently accept an untrusted certificate, the file * .truststore in the user's home directory is written. The default * keystore (for client certificates) is the file .keystore in the user's * home directory. This can be overridden by setting the system property * javax.net.ssl.keyStore. If the name of the keystore ends in * .p12, it is assumed that the keystore is in PKCS12 format, * otherwise the default format as specified in the JRE security-configuration * is used. * * Important Note about client authentication: * * At the time of this writing, a serious bug exists in apache 2.0.x * which prevents POST requests when SSL renegotiation is about to happen. * Renegotiation is triggered by a location-based (or directory-based) change of * the SSLVerifyClient directive in apache. Therefore you can not protect * a sub-area of an otherwise unprotected SSL server. You can circumvent that by * setting up a virtualhost which is configured to perform SSL client * verification for the complete virtualhost. Attached to the bug report * at ASF * Bugzilla, there are several patches which claim to fix the problem. * However in that same report, other users complain about those patches to be * ineffective. Therefore, the author recommends avoiding re-negotiation * alltogether by using the virtualhost aproach described above. It is the * understanding of the author, that this bug has been fixed for apache 2.2, * however the author did not verify that. Test-Reports from users running * apache 2.2 are welcome. * |
*
| storeBufferedImage | *false * Deprecated * {@link wjhk.jupload2.policies.PictureUploadPolicy} |
* This parameter indicates that the preview image on the applet is kept in
* memory. It works really nice under eclise. But, once in the navigator, the
* applet runs very quickly out of memory. So I add a lot of calls to
* {@link wjhk.jupload2.filedata.PictureFileData#freeMemory(String, UploadPolicy)}
* , but it doesn't change anything. Be careful to this parameter, and let it to
* the default value, unless you've well tested it under all your target client
* configurations. * This parameter will probably never be correctly implemented. |
*
| stringUploadError | *Since 3.2.0: "^ERROR: (.*)$" for all upload policies * Empty string ("") [if using DefaultUploadPolicy] * "ERROR: (.*)" [if using CopperminUploadPolicy] * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} * Since 2.9.2rc4 |
* This string is a regular expression. It allows the applet to test that
* the server has detected an error in the upload. If this parameter is given to
* the applet, the upload thread will try to match this regular expression
* against each line of the server response body. If a group is found, it
* is considered as the error message, and will be displayed to the user. * If the match is successfull once, the upload is considered to have failed. * and {@link wjhk.jupload2.exception.JUploadExceptionUploadFailed} is thrown. * If the expression contains a hunt-group, the matching contents of that group * is reported to the user. For example: If let the default value "^ERROR: * (.*)$" here, the applet will find an error if at least one line returned in * the server response begins with "ERROR: ". Then, all characters that follow * are extracted as the error message. So, if the server response contains the * line "ERROR: md5sum check failed", the string "md5sum check failed" is used * for the exception message. But if it returns a line "maybe ERROR: is it an * error?", then the applet won't find any error in the server response. * Note: you can put line breaks in the error message. The message must * be in one line in the HTTP response. To display a line break to the user, * just put the two characters \n in the http response (would be a "\\n" in java * or PHP). |
*
| stringUploadSuccess | *"^SUCCESS$" * empty string ("") since 2.9.0 * (was ".* 200 OK$" before) * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* This string is a regular expression. It allows the applet to test that
* the server has accepted the upload. If this parameter is given to the applet,
* the upload thread will try to match this regular expression against each
* lines returned from the server. * If the match is successfull once, the upload is considered to be a success. * If not, a {@link wjhk.jupload2.exception.JUploadExceptionUploadFailed} is * thrown. * The default test expression testes that the web server returns no HTTP error: * 200 is the return code for a successfull HTTP request. It actually means that * postURL is a valid URL, and that the applet was able to send a request to * this URL: there should be no problem with the network configuration, like * proxy, password proxy...). * But it doesn't mean that the uploaded files have correctly be managed * by the server. For instance, the URL can be http://sourceforge.net, which, of * course, would not take your files into account. * So, as soon as you know a regular expression that test the return from the * target application (and not just a techical HTTP response code), change the * stringUploadSuccess to this value. For instance, the default value will be * matched if the HTTP body content of the server response contains one line * that is exactly 'SUCCESS', without any other character. This 'success' means * that the pictures have correctly uploaded to the server, and that he * successfully managed the uploaded files. |
*
| stringUploadWarning | *"^WARNING: (.*)$" * {@link wjhk.jupload2.policies.DefaultUploadPolicy} * Since 3.4.2 |
* This string is a regular expression. It allows the applet to test that
* the server has detected a warning was generated by the server. This warning
* is just a warning, that will be displayed to the user, as is. There may be
* several warnings in the server return. If one or more warning is/are
* received, the message(s) will be displayed to the user. * If the expression contains a hunt-group, the matching contents of that group * is reported to the user. For example: If you let the default value "^WARNING: * (.*)$" here, the applet will find an error if at least one line returned in * the server response begins with "WARNING: ". Then, all characters that follow * are extracted as the error message. So, if the server response contains the * line "WARNING: Bad encoding", the string "Bad encoding" is displayed as * warning message to the user. But if it returns a line "maybe WARNING: is it * an error?", then the applet won't find any warning in the server response. * Notes: |
*
| targetPictureFormat | *Empty String * {@link wjhk.jupload2.policies.PictureUploadPolicy} |
* This parameter can contain a list to convert image formats
* * Example 1:{@code "png,bmp:jpg;gif:png;"} *
* format: {SOURCEFORMAT{,SOURCEFORMAT*}:TARGETFORMAT;}*
*
* see keepOriginalFileExtensionForConvertedImages |
*
| uploadPolicy | *DefaultUploadPolicy * * see {@link wjhk.jupload2.policies.UploadPolicyFactory} |
* This parameter contains the class name for the UploadPolicy that should * be used. If it is not set, or if its value is unknown from * {@link wjhk.jupload2.policies.UploadPolicyFactory#getUploadPolicy(JUploadContext)} * , the {@link wjhk.jupload2.policies.DefaultUploadPolicy} is used. | *
| urlToSendErrorTo | *null * * {@link wjhk.jupload2.policies.DefaultUploadPolicy} |
* If this url is given, and an upload error occurs, the applet posts all
* debug output to this address. It's up to this URL to handle this message. It
* is possible to just store the file, or to log the error in a database, or to
* send a mail (like the mail.php script given with the coppermine pack). * Notes: |
*
* Below, an example of how to put the applet into a PHP page is shown: *
*
* <applet name="JUpload" code="wjhk.jupload2.JUploadApplet"
* archive="plugins/jupload/wjhk.jupload.jar"
* <!-- Applet display size, on the navigator page -->
* width="500" height="700"
* <!-- The applet uses some javascript functions, so we must allow that : -->
* mayscript="true">
* <!-- No parameter is mandatory. We don't precise the UploadPolicy, so
* DefaultUploadPolicy is used. The applet behaves like the original
* JUpload. (jupload v1) -->
* <param name="postURL" value="http://some.host.com/youruploadpage.php">
* Java 1.5 or higher plugin required.
* </applet>
*