I am using primefaces3.5 fileupload control. When I upload a wrong format file then it shows a error message "Wrong format etc". After that when I upload a correct format file then it uploads fine but does not remove the error message.While searching I found this solution on primefaces forum but it is also not working.
How can I remove the error message on subsequent uploads?
Here is my code
<p:fileUpload id="fu"
allowTypes="/(\.|\/)(DOC|DOCX|doc|docx|ppt|pptx|xls|xlsx|pdf)$/"
onstart="loadingCursor();" oncomplete="simpleCursor();"
multiple="false" mode="advanced" sizeLimit="52428800"
showButtons="false"
fileUploadListener="#{documentInsertController.uploadPListener}"
label="Browse"
invalidSizeMessage="File size exceeds limit 45 MB "
value="#{documentInsertController.file}" auto="true"
invalidFileMessage="Invalid file type.Only doc,ppt,xls and pdf files allowed."
>
<h:message id="docMSG" for="fu"></h:message>
</p:fileUpload>
Worked for me with PrimeFaces 3.5:
<script type="text/javascript">
$(document).ready(function () {
fileuplaod_wgt.buttonBar.find("button.cancel").bind("click", function (e) {
clearInvalidFileMsg();
});
});
function clearInvalidFileMsg() {
fileuplaod_wgt.uploadContent.find("tr.ui-state-error").remove();
}
</script>
And I've added widgetVar="fileuplaod_wgt" in the p:fileUpload. Then cancel button works and removes invalid files.
It is not a permanent solution. Just a workaround until it will be fixed within PrimeFaces itself. Check: https://code.google.com/p/primefaces/issues/detail?id=3652
Related
I am using Primefaces v6.2.13 to upload a file. Works fine for files with extension, but crashes when trying to upload file without extension.
This is the part of xhtml used to render upload button
<p:fileUpload value="#{addFileController.file}"
mode="simple" skinSimple="true"
rendered="#{!addFileController.uploadDisable}"
label="Choose file"
allowTypes="#{addfileController.allowedTypes}" />
When I choose file, nothing happens, but as soon as I click the upload button, it throws an error, that I am unable to catch in my code, since it first calls some upload mechanism in PrimeFaces and later the code that I wrote.
The error is:
javax.faces.FacesException: File must have an extension
at org.primefaces.util.FileUploadUtils.getValidFilename(FileUploadUtils.java:54)
and the problematic part of the code inside class looks like this
...
String name = FilenameUtils.getName(filename);
String extension = FilenameUtils.EXTENSION_SEPARATOR_STR + FilenameUtils.getExtension(filename);
if (extension.isEmpty()) {
throw new FacesException("File must have an extension");
}
....
}
Any idea how to deal with this? I was thinking about adding some attribute to xhtml to disable uploading files without extension, since I don't want to edit PF source code.
I'm trying to write a casperJS program that can navigate and download PDFs. If I can grab an actual URL corresponding to the PDF it's pretty straight-forward, but that isn't always the case. To test this, I've been working with this simple example locally:
<html>
<head>
</head>
<body>
<h1 class="page-title">Hello</h1>
<a id='1' href="test.pdf" target="_blank">one</a>
</body>
</html>
Basic casper:
casper.start('file:///opt/templates/templates/src/main/resources/casperjs/example.html').then(function() {
this.echo('started')
});
casper.then(function() {
this.waitForSelector('a', function() {
this.click('a');
});
});
casper.wait(1000, function() {
this.echo(JSON.stringify(this.popups[0]));
});
casper.run();
When I run this, the (only) popup that's present is a blank HTML page that never loads. It's also worth noting that if you test this without the 'target="_blank"' (i.e. the PDF opens in the same tab), the 'resource.received' event will be emitted (with null content type), but loading the resource will fail:
[warning] [phantom] Loading resource failed with status=fail: file:///opt/templates/templates/src/main/resources/casperjs/test.pdf
Is there any good way to handle links that will open/download PDFs in some generic way? You can hook into 'navigation.requested' perhaps and download there, but I don't think there's a wonderful way to figure out that the nav is for a PDF (the URL may not always have file extension).
I am implementing Cloudinary Jquery Upload. From my file upload webpage, if I surf to another website ( google.com, or any external website), and then click on the back button on the browser into this same file upload page, the upload fails.
The error message I gotten back is (from Firebug):
400 Bad Request
{"error":{"message":"Upload preset Must specify upload preset when using unsigned upload”}}
I did not enable unsigned upload on the Cloudinary management console
because my intention is a signed upload
This is the JSON data that is created at the backend for data-form-data:
{"timestamp":1409146953,"callback":"http://newappsure.herokuapp.com/vendor/cloudinary/cloudinary_cors.html","signature":"19071a3e822eed51238454e359589f52cccca042","api_key":"224456847515364”}
Below is the javascript and input HTML:
<script type="text/javascript”>
$.cloudinary.config({cloud_name:'dashy', api_key:’XXXXXXXXXXXXXXX'});
</script>
<input name="file" type="file" id="uploadinput" class="cloudinary-fileupload" data-cloudinary-field="image_upload"
data-form-data="" ></input>
<script>
$.ajax({
url: '/filer',
type: 'POST',
success: function(response){
$('#uploadinput').attr('data-form-data', response);
}
});
</script>
This is the Ruby backend that generates JSON:
post '/filer' do
ts = Time.now.getutc.to_time.to_i.to_s
secret="XXXXXXXXXXXXXXXXXXXXXX"
altogether="callback=http://newappsure.herokuapp.com/vendor/cloudinary/cloudinary_cors.html×tamp="+ts+secret
sig=Digest::SHA1.hexdigest altogether
ts = Time.now.getutc.to_time.to_i
{:timestamp => ts, :callback => "http://newappsure.herokuapp.com/vendor/cloudinary/cloudinary_cors.html", :signature => sig, :api_key =>"XXXXXXXXXXXXXXXX"}.to_json
end
Please help me understand what did I do wrong?
While your solution may work, the more optimal way is to update the upload parameters to call $(...).fileupload({formData: data}) where data is the parameters hash (not JSON serialized).
For more information:
http://support.cloudinary.com/entries/24950218-Why-is-updating-a-cloudinary-fileupload-field-dynamically-not-working-
Got it working by forcing the page to reload with the following snippets (ref: https://stackoverflow.com/a/9217531/3781343 and http://www.webdeveloper.com/forum/showthread.php?137518-How-to-refresh-page-after-clicking-quot-Back-quot-button)
<input type="hidden" id="refreshed" value="no">
<script type="text/javascript">
onload=function(){
var e=document.getElementById("refreshed");
if(e.value=="no")e.value="yes";
else{e.value="no";location.reload();}
}
</script>
Following code works in Chrome (22.0) but not in Safari (6.0)
<!DOCTYPE html>
<html>
<head>
<script>
function onGo(e) {
var fr = new FileReader();
var file = document.getElementById("file").files[0];
fr.onload = function(e) {
var data = new Uint8Array(e.target.result);
var blob = new Blob([data], {type: 'audio/mpeg'});
var audio = document.createElement('audio');
audio.addEventListener('loadeddata', function(e) {
audio.play();
}, false);
audio.addEventListener('error', function(e) {
console.log('error!', e);
}, false);
audio.src = webkitURL.createObjectURL(blob);
};
fr.readAsArrayBuffer(file);
}
</script>
</head>
<body>
<input type="file" id="file" name="file" />
<input type="submit" id="go" onclick="onGo()" value="Go" />
</body>
</html>
In Safari, neither callback (loadeddata nor error) is called.
The content used is an mp3 file, which is normally played back with audio tag.
Is there any special care needed for Safari?
Many years later, I believe the example in the OP should work just fine. As long as you somehow set the mime type when creating the blob, like the OP does above with the type property of the options passed in:
new Blob([data], {type: 'audio/mpeg'});
You could also use a <source> element inside of an audio element and set the type attribute of the <source> element. I have an example of this here:
https://lastmjs.github.io/safari-object-url-test
And here is the code:
const response = await window.fetch('https://upload.wikimedia.org/wikipedia/commons/transcoded/a/ab/Alexander_Graham_Bell%27s_Voice.ogg/Alexander_Graham_Bell%27s_Voice.ogg.mp3');
const audioArrayBuffer = await response.arrayBuffer();
const audioBlob = new Blob([audioArrayBuffer]);
const audioObjectURL = window.URL.createObjectURL(audioBlob);
const audioElement = document.createElement('audio');
audioElement.setAttribute('controls', true);
document.body.appendChild(audioElement);
const sourceElement = document.createElement('source');
audioElement.appendChild(sourceElement);
sourceElement.src = audioObjectURL;
sourceElement.type = 'audio/mp3';
I prefer just setting the mime type of the blob when creating it. The <source> element src attribute/property cannot be updated dynamically.
I have the same problem, and I spend a couple days troubleshooting this already.
As pwray mentioned in this other post, Safari requires file extensions for media requests:
HTML5 Audio files fail to load in Safari
I tried to save my blob to a file, named it file.mp3 and Safari was able to load the audio that way, but after I renamed the file to have no extension (just "file"), it didn't load.
When I tried the url created from the blob in another tab in Safari:
url = webkitURL.createObjectURL(blob);
it download a file right away called "unknown", but when I tried the same thing in Chrome (also on Mac), it showed the content of the file in the browser (mp3 files start with ID3, then a bunch of non-readable characters).
I couldn't figure out yet how I could force the url made of blob to have an extension, because usually it looks like this:
blob:https://example.com/a7e38943-559c-43ea-b6dd-6820b70ca1e2
so the end of it looks like a session variable.
This is where I got stuck and I would really like to see a solution from some smart people here.
Thanks,
Steven
Sometimes, HTML5 audio can just stop loading without any apparent reason.
If you take a look to the Media Events (http://www.w3schools.com/tags/ref_eventattributes.asp) you´ll see an event called: "onStalled", the definition is "Script to be run when the browser is unable to fetch the media data for whatever reason" and it seems that it should be helpful for you.
Try listening for that event and reloading the file if necessary, with something like this:
audio.addEventListener('onstalled', function(e) {
audio.load();
}, false);
I hope it helps!
Just use source tag in audio.
<audio controls>
<source src="blob" type="blobType">
</audio>
I'm seeing a really strange behavior under DOJO 1.8.0. I'm trying to asynchronously upload a file. The file is uploading just fine and I'm getting the payload as expected, but when clicking the submit button the tags and everything in between is inexplicably deleted! It just vanishes. (NOTE: I've isolated this testing to a test page, so there's nothing else at play that would account for it. You're looking at the entirety of the code.)
require(['dojox/form/Uploader',
"dojo/request/iframe",'dojo/dom','dojo/on',
'dojox/form/uploader/plugins/IFrame', 'dojo/domReady!'],
function(Uploader,iframe,dom,on){
on(dom.byId("myButton"), "click", function(){
iframe.post("UploadFile.php",{
form: dom.byId("myForm"),
handleAs: "json"
}).then(function(data){
console.log(data);
}, function(err){}
);
});
<form method="post" id="myForm" enctype="multipart/form-data" >
<input name="uploadedfile" type="file" data-dojo-type="dojox.form.Uploader"
label="Select Some Files" id="uploader" />
<input id="myButton" type="button" value="Submit" />
</form>
Any ideas from anyone with DOJO 1.8 experience? I've been using /dojo/io/iframe just fine with versions 1.6 thru 1.7. This started happening only with 1.8 using the new /dojo/request/iframe code.
See http://jsfiddle.net/seeds/XD4Dc/1/
The form element is set to have target of dojo's injected iframe. Then form gets like, 'dijitHidden' with abs position -1000 top/left. Cant see why tbh.
There's a fix in the fiddle, add to your callback:
with(dom.byId("myForm").style) {
position = "";
left = "";
top = "";
}
I took this issue to the DOJO-Interest group and it was found to be bug with DOJO 1.8.0. It'll be fixed with the upcoming 1.8.1 release.
http://bugs.dojotoolkit.org/ticket/15939
From the bug report:
The form wasn't getting "eaten", but rather the position was getting set on it and moved out of the viewport because of some faulty logic to check if the form was in the DOM. This has been fixed and should be in 1.8.1.