I've been given this old Apache Wicket 1.5 web application.
All the URLs seem to end in ?xxx, where xxx is a number. This seems to be a Wicket "feature" that allows you to version / cache previously shown webpages. As nice as it might sound, in practical terms this is nothing more than a headache for all users involved, as even if the underlying data shown on the page changes and the user forces a page refresh, the old, stale page is still reloaded.
I've browsed online and in Wicket's docs it seems to be referred as "versioning".
I've tried to disable it by calling setVersioned(false) but it was of no avail -- I see no observable difference. Does anyone know how to get this to work?
Thanks
The problem is that your application caches the data into the models. In Wicket terminology this is called a static model.
For example:
Person person123 = personService.get(123);
// a static model
page.add(new Label("personMood", new Model(person123.getMood())));
Here the Label will always show the mood of the person at the time of instantiation of the Label. The person may change his/her mood in the next second but the Label will still show the old/cached value.
// a dynamic model
page.add(new Label("personMood", new Model<String>() {
#Override public String getObject() {
return person123.getMood();
}
}));
here the Label will render the current mood of the person at every render of this label/page.
The pageId in the url tells Wicket which stateful page to lookup and load from the page store. Only stateful pages have such id. If you want to get rid of it then you should use only stateless components and behaviors in your page. There is wicket-devutils module which provides StatelessChecker to help you identify the reason when a Page becomes stateful by accident.
In your case I am not sure which solution would be easier - to rework the Model(s) or to make the page stateless. Usually the first is easier.
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.
How can i pass or preserve the state of my store between pages using PageView?
By example, I'm trying to upload an image at the first page to edit, and pass to a second page where i want to show the image with a form. Im using MVC, and the image is set via controller (store), but it's not working. I've been made some tests and sometimes, at debugging runtime, the image is shown at the second page. But, sometimes even debugging it isn't shown and its value is null.
I tried with AutomaticKeepAliveClientMixin also, but the behavior is the same.
Someone can tell me what i'm doing wrong or what i'm missing?
I think using singleton can solve your problem, actually I think I had this problem in two apps I made.
I used get_it plugin, this package creates singletons easily for you and it's simple to retrieve anywhere in the app without using context.
First, register your MobX as Singleton, I do it on main:
getIt.I.registerSingleton<YourStore>(YourStore());
Retrieve the same instance of your Store, if you have observables in the first page and call an action on the second page, it will trigger the observables in the first page or wherever you used any observable from this instance of Store.
GetIt.I<YourStore>().changeImageFromFirstPage();
You can call GetIt.I().youraction() anywhere in your app, it will trigger the observables you created on this Store.
final list = Provider.of<TodoList>(context);
in the MobX document, there is a provider that can be used as the above code.
I use GetIt too, it is really awesome.
there is a sample for this in the following URL for the MobX:
https://mobx.netlify.app/examples/todos
GWT is used and the application is deployed on WebLogic using HTTPS.
The performance is poor and with F12 Developer Tools, we could see that blank.html is downloaded multiple times. This is clearly related to GWT but we have not been able to figure out why.
The following is from javascript:
defineSeed(2613, 2614, makeCastMap([Q$BaseModelData, Q$ModelData, Q$Theme, Q$Serializable]), Slate_0);
var SLATE;
function $clinit_GXT(){
$clinit_GXT = nullMethod;
IMAGES = new XImages_generatedBundle_0;
MESSAGES = new XMessages__0;
SSL_SECURE_URL = getModuleBaseURL() + 'blank.html';
}
This is from GWT.java:
/**
* URL to a blank file used by GXT when in secure mode for iframe src to
* prevent the IE insecure content. Default value is 'blank.html'.
*/
public static String SSL_SECURE_URL = GWT.getModuleBaseURL() + "blank.html";
Does anyone know under what circumstances blank.html is called?
Thanks!
This is from GWT.java:
This is actually from GXT.java.
This is used in a few cases when creating an <iframe> element, so that IE won't give errors if your site is hosted from SSL. I can actually only find one case (as of GXT 3.1.1) which uses this, in Layer.java. Only IE pages loaded from https urls will make use of this.
The Layer class uses this as a "shim", a way to prop up some DOM elements above overs, and work around some browser bugs (typically plugin or iframe related). Menus and popup dialogs use this to ensure that they don't appear "underneath" content that they should be "above".
This file is very small - just enough HTML to convince IE than the iframe has correctly loaded, and no more. It never changes, and should load nearly instantly.
As far as performance goes, this should only happen when a Menu or Window/Dialog/Tooltip is shown - these shouldn't be happening on app startup usually, at least not more than a window or two. Additionally, the browser should recognize that it is loading the same element and cache it correctly, and not load it multiple times (though it might be listed several times as hitting the cache). If the server has instructed the browser to never cache the file, that is something you should look at changing.
In short, this is very unlikely to be the cause of any performance issues, at least in GXT itself. If somehow you have the shim enabled on every single widget in your project, this should not be required. If the file is loading slowly, something may be very wrong with your server configuration.
For reference, here is the entire file:
<html></html>
My question is very basic on one hand but on the other hand the general situation is more complex, plus I cannot really get any working sample.
I'm developing/maintaing a web-application which is currently in transition from GWT code base into Ember.js.
Most of the newer code already relies on Ember.js and I think it's really awesome.
The problem is we cannot use Ember Router as all the request are being handled by the GWT.
In order to enabled the application run in this unusual configuration we have special JavaScript files that create our Ember main objects (Controllers & Models) for us.
As you can imagine navigation between tabs is cumbersome and is handled by GWT who creates Ember objects when needed. We are in transit toward a brave new world Ember Router and all.
But in the meantime, this is the problem I'm facing right now.
The user clicks a link which opens a page that contains some Ember based table.
The data is retrieved form the server using some Ajax code. Upon success it spawns a forEach loop which tries to pushObject all the received date into our Ember based components.
My problem happens when the user quickly switches between tabs. In this case the first list of object has not finished rendering yet and suddenly there's a new set of objects to handle. This causes Ember to throw errors like:
"Uncaught Error: Cannot perform operations on a Metamorph that is not in the DOM. "
and
"Uncaught NotFoundError: An attempt was made to reference a Node in a context where it does not exist."
Is it possible to prevent the loop from trying to render?
I've tried checking if the controller in question is already inDOM and it is, is there a way to notify Ember this object is no longer valid?
Sorry for a lengthy question and lack of running sample.
I'd probably modify the switch tab code to only execute afterRender has completed, that way you aren't mucking with ember objects while they are being used.
Ember.run.scheduleOnce('afterRender', this, function(){
// call GWT switch tab routine
});
Thank you Daniel and Márcio Rodrigues Correa Júnior. eventually what I did is to add a patch that would check the current context of the application (in my case the currently selected tab). If upon receiving the AJAX response the application is in the correct context (meaning the user haven't change the tab) go on. Otherwise just ignore the response and do not try to render it.
Now it seems to be working
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...