Everything about the uploader is working perfectly, but one callback seems to do nothing:
.bind('fileuploadchange', function (e, data) {
console.log("foo");
})
Binding to the change event never returns anything... so my question:
1) Is this a bug? I'm using the most recent version.
2) Is there another/better way to detect when files are manually removed from the upload queue (something more elegant than reading DOM elements)?
There might be a bit of misunderstanding in what the fileuploadchange event does.
The admittedly limited documentation for the change event states:
Callback for change events of the fileInput collection.
That means it's an event callback for the native change event of all the file input elements of the fileupload widget.
This event only fires if the user selects one or more files via the file picker dialog that is displayed after clicking on the file input button.
Technically, the basic fileupload library doesn't keep track of a queue.
It's up to the UI implementation to handle this, via the various callbacks provided by the basic library.
Until the user actually starts the file upload, there is technically nothing the basic library could keep track of.
And as soon as a file upload is started, the done and fail events are your basic building blocks.
By the way, the sample UI implementation handles the removal of items that have not been started yet by triggering a manual fail event.
Related
I have a panel used in multiple pages in an app we're developing. In this panel is a FileUploadField that uses AjaxFormSubmitBehavior (extended as FileUploadBehavior) on "change" to upload a file, which I then add to a list via ajax, update the view, clear the FileUploadField, and then allow them to select another file. And this is in fact exactly what happens in one of the pages using the panel...but not in another. In the non-working page, the first file selected is repeated over and over regardless of what file is picked after the first.
In the onSubmit of the behavior, we get the the FileUpload object which is supposed to be different between requests. I can see in the debugger that the FileUpload is the exact same object as the previous request, not merely carrying the same payload.
I'm scrutinizing the usage of the panel on the two pages and see no material differences. I can see the file control on the page DOES show the changed file name while I sit at my breakpoint on the server (so I suspect whatever is going wrong is on the java side). But I can't figure out why they behave differently or see where it's going wrong. The panels and pages are large and complex, so here's snippets of the relevant pieces.
FileUploadBehavior.onSubmit(AjaxRequestTarget) :
FileUploadField fileUploadField = (FileUploadField) fileUploadContainer.get("fileUploadField");
FileUpload fileUpload = fileUploadField.getFileUpload();
[...]
//clear file input after each request for next upload.
fileUploadField.clearInput();
target.add(fileUploadField);
I have a break right after this line and can see the first file gets repeated. The code that instantiates the field and behavior in the panel looks like:
FileUploadField fileUploadField = new FileUploadField("fileUploadField");
fileUploadField.add(new FileUploadBehavior("change", maxFileSize).setDefaultProcessing(false));
fileUploadContainer.add(fileUploadField);
The html tag:
<input wicket:id="fileUploadField" class="form-control" type="file" id="formFile" multiple>
I feel like the fact that it works in one page and not in another leads me to think the problem is outside the panel. The fact that the control in the browser shows the 2nd filename during test leads me to think it's on the java side. But nothing about the file event or definition happens outside the panel itself. The form elements are declared identically, and both have multipart enctypes when the pages render. Both successfully upload their first file. I'm kind of not even sure where to look for why wicket is re-using the FileUpload object in one page but not in another.
I should mention that we use Apache Wicket 6.26.
update: I looked into the source of FileUploadField, and it has an explicit check on whether FileUploads is null in it's internal property, and if so returns it without checking the actual request. I don't see any way to clear this value between requests. clearInput() doesn't affect it from what I see. I'm more confused by how this is working in one page than why it's not in the one where it doesn't now. I also don't know how to make the class 'reset' between requests.
Okay, figured this out. As martin-g pointed out, the fileUploads is set null in onDetach(), which I discovered about an hour after my update. The problem is that the onDetach() first tries to null out the model object. But that method was blowing up because there was no method 'fileUploadField' on the model attached to the form which was a compound property model. The page that worked does NOT use a compound property model for the form. For some reason, when this error occurred, it was being swallowed somewhere in the call stack and did not end up in my console log.
My solution was to provide a local model to the fileUploadField since that's not how I'm interacting with the control anyway (I'm using ajax and getting the FileUpload directly each time). That fixed it. It now works everywhere.
I use SAP standard library: Inbox.
in library class S3.controller by tap on attachments icon is onTabSelect event executed, witch makes
this.fnDelegateAttachmentsCreation();
this.fnFetchDataOnTabSelect("Attachments");
this.fnHandleAttachmentsCountText("Attachments");
this.fnHandleNoTextCreation("Attachments");
break;
fnFetchDataOnTabSelect makes an asynchronous call. During this call is fnHandleAttachmentsCountText already executed, so the update of attachments count occurs before the request for attachments is ready. As far the request for attachments is ready, there is no update for title executed.
On screenshot is AttachmentCountText „Attachnents (1/1)“, that comes from previously selected item.
It should be „Attachements (2/2)".
Also if response comes too quick, then view changes to loading view after it received the answer from request.
If list of attachments was updated from request callback, then it should not be updated second time.
Here it seems, that there is something on loading, but request is already finished.
How could be Inbox extended, to update the attachment header and content after request is ready?
used SAPUI5-Version: 1.71.4
You are using the standard bsp-application ca_fiori_inbox?
You didn't create an extension project of the application ca_fiori_inbox with custom coding?
If that's the case, it's a bug in an standard application delivered by the SAP. SAP releases so called notes to fix bugs in their standard applications.
You can import notes in your system via the transaction SNOTE. May ask a SAP Basis Administrator from your company for help.
The following notes exactly describe your problem
2873960
2823664
2916255
2901520
If you already extended the SAP standard application(MyInbox) without using ExtensionPoints codechanges in the standard application will not affect your custom extension.
When overriding a controller method, any functionality that was previously provided by it is no longer available. Likewise, any future changes made to the original controller method implementation will not be reflected in the custom controller.
In this case you could still implement the note and check the changes in the standard controller vs. your custom controller on your system and change the respective lines in your custom coding.
Don't fix SAP coding. Report it and get a fix.
The Note 2873960 corrects coding in an abap class, not in the bsp-application(ca_fiori_inbox). So definitly import the note and check if it's fixing your problem.
I actually do not know, how the app works, but I want to give it a try.
Since it is an asynchronous function, you can always also wait for the function until it is done. So in your case, you could try to set an await keyword in front of the function.
await fnFetchDataOnTabSelect("Attachments");
This will now wait on this position until it has finished the function call before it will call the next functions. In addition to that you also need to set the upper function onTabSelect to async. So in the end it should look something like this.
onTabSelect: async function() {
// ...
this.fnDelegateAttachmentsCreation();
await this.fnFetchDataOnTabSelect("Attachments");
this.fnHandleAttachmentsCountText("Attachments");
this.fnHandleNoTextCreation("Attachments");
// ...
}
Although the Web IDE maybe shows you errors, it does work, since it is an official JavaScript API.
By default, TinyMCE's autosave plugin stores the editor's text in localStorage. Is there a way to tell it to use a different storage engine? Ultimately what I want to do is set up a listener on the storeDraft event so I can persist the contents to our server so the user can access the contents even after the autosave_retention limit has been surpassed. I know that I can set the autosave_rentention to 0 but even when I do I can see that it still writes the data to localStorage -- it just removes it (though, sometimes not immediately and it seems like a page reload short circuits that in some cases).
So basically, I'd like to hit 2 birds with one stone. I'd like to stop TinyMCE from storing the data in localStorage and, if I can specify a different "data store", then perhaps I can point it to my ajax handler which will persist to the back end.
Any advice would be greatly appreciated!
thnx,
Christoph
The autosave plugin is designed to work with local storage and has no option to change to a different storage mechanism. If you want to store the data on your server you would typically that with some custom code that uses either (a) TinyMCE events or (b) a timer to get the editor's current content and then send it to the server.
If you want to use TinyMCE events (https://www.tiny.cloud/docs/advanced/events/#editorevents) to trigger this process you would have code along these lines:
tinymce.init({
selector: "textarea",
...
setup: function (editor) {
editor.on('init change NodeChange Dirty', function (e) {
// 1. use getContent() to extract the editor's current HTML
// 2. send the HTML to your server
});
}
});
If you want to use a basic timer (e.g. setTimeout()) you would use that to trigger the same two actions as the sample code above.
In theory you could modify the autosave plugin to send data to your server as opposed to storing the data in local storage but I think you can do what you need in a far simpler way without needing to dig into the ~200 lines of code in the existing plugin.
I am trying to port a WinForms app for use with Mono, and I've recently noted that calling Form.Show() from another form will either do nothing or cause the new form to flash and disappear. I read something about the new form needing a message pump, which is accomplished with Application.Run(), but that's already been called. Any idea why this doesn't work? I can't use ShowDialog because my program relies on events fired by completed async tasks, and I don't want to block a ton of extra threads that will be done right after the Show call.
Have you tried to hide your current form before showing/displaying your new one?
Seems to me like your form is indeed being displayed but for some strange reason it's being delegated to the background. Worth a shot.
In our app we need to check if the data is saved when we are in a particular place before navigating away from it. So the user should be able to negate a browser back button request. But by the time that the history value change event is received the url has already been changed. The History class doesn't seem to have a way to restore the url back. Anybody have any ideas?
In GWT 2.1 you get Activities and Places. And activity has a maystop method, which is exactly what you want, if I understand you correctly.
Use a window.onunload or window.onbeforeunload javascript callback to confrim/save state.
onbeforeunload example
I haven't actually implemented this behavior yet, but here is my plan and maybe it will work for you.
1) Each time you receive an onHistoryChanged event and decide to allow it, save the current historyToken in an instance variable somewhere.
2) Keep track of activity on the page that should block navigation. Use a data structure that can keep track of multiple activities, like multiple file uploads, multiple edits, etc.
3) When you receive a new onHistoryChanged event, if your data structure from #2 indicates that it's not safe to navigate, avoid changing the page and restore the historyToken that you saved in #1. I'm assuming that you can do this either by:
a) Calling History.newItem(oldHistoryToken, false) or
b) Calling History.newItem(oldHistoryToken, true) and keeping a flag to force the next onHistoryChanged to be ignored.
Again, I haven't actually implemented this so let me know how it works out.
If you have links that allow the user to leave the app and you want to prevent that as well, you'll need to also add an onbeforeunload.
Have a look at the PlaceManagerImpl class from the gwt-platform framework. Especially the onValueChange() method and the methods dealing with the onLeaveQuestion field.
Hope that helps.
In this issue report, t.broyer explains in his comment that such behavior was planned during design of Places framework. The most important part is:
mayStop was a mistake, or it should have only been called when unloading the app, not for internal navigation within the app.
So probably it's better to not use it at all...