How does one manage state in a GWT application? I am much more experienced in JSF development and every bean is scoped to either request, session, application, conversation, page etc etc. How does that work in GWT? Any reading tips on state management in GWT?
It depends on whether or not you're presenting your site as a browser-based application or a series of pages. In the application style, the user rarely navigates away from the app's URL, so the GWT module is long-lived and the server is relatively stateless. In the sequence-of-pages style, the GWT module would be restarted each time the user browses to a new URL, so the server has to maintain state to send back to the client on each page load.
Writing state-management for the application style uses the same patterns as any kind of desktop or server app. You usually have some service object that brokers data exchange with the server (GWT-RPC or RequestFactory) and the broker is made available to the various objects in your module that require state. Objects store their state in fields and have a lifetime corresponding to their usefulness (e.g. Widgets vs. caches vs. ephemeralia).
Well, in general I view it this way: Usually, your GWT app is one website with a lot of javascript code. In that code, all fields (member variables) of all the client java classes are your state. Additionally, you can embed IDs or variable values in the DOM of the dynamic website (e.g. an attribute "xyz" as part of an tag). They also contribute to your state. Therefore, all the "data" plus the DOM is the state.
On a coarser level, you can encode state's in the URL after a "#" sign. They are called "Places" or "History", depending on which implementation you choose. (GWT's History, mvp4g, ...)
If you need some user management, you can then request a token from the server after successful authentication, store it locally in the client (change it's state), and then include it for each server request.
Related
I am investigating a slow login time and some profile synchronisation problems of a large enterprise AEM project. The system has around 1.5m users. And the website is served by 10 publishers.
The way this project is built, is that they have enabled the SAML_login for all these end-users and there is a third party IDP which I assume SAML_login talks to. I'm no expert on this SSO - SAML_login processes, so I'm trying to understand if this is the correct way to go at the first step.
Because of this setup and the number of users, SAML_login call takes 15 seconds on avarage. This is getting unacceptable day by day as the user count rises. And even more importantly, the synchronization between the 10 publishers are failing occasionally, hence some of the users sometimes can't use the system as they are expected to.
Because the users are stored in the JCR for SAML_login, you cannot even go and check the home/users folder from crx browser. It times out as it is impossible to show 1.5m rows at once. And my educated guess is, that's why the SAML_login call is taking so long.
I've come accross with articles that tells how to setup SAML_login on AEM, and this makes it sound legal for what it is used in this case. But in my opinion this is the worst setup ever as JCR is not a well designed quick access data store for this kind of usage scenarios.
My understanding so far is that this approach might work well but with only limited number of users, but with this many of users, it is an inapplicable solution approach. So my first question would be: Am I right? :)
If I'm not right, there is certainly a bottleneck somewhere which I'm not aware of yet, what can be that bottleneck to improve upon?
The AEM SAML Authentication handler has some performance limitations with a default configuration. When your browser does an HTTP POST request to AEM under /saml_login it includes a base 64 encoded "SAMLResponse" request parameter. AEM directly processes that response and does not contact any external systems.
Even though the SAML response is processed on AEM itself, the bottle-necks of the /saml_login call are the following:
Initial login where AEM creates the user node for the first time - you can look at creating the nodes ahead of time. You could write a script to create the SAML user nodes (under /home/users) in AEM ahead of time.
During each login when the session is first created - a token node is created under the user node under /home/users/.../{usernode}/.tokens - this can be avoided by enabling the encapsulated token feature.
Finally, the last bottle-neck occurs when it saves the SAMLResponse XML under the user node (for later use required for SAML-based logout). This can be avoided by not implementing SAML-based logout. The latest com.adobe.granite.auth.saml bundle supports turning off the saving of the SAML response. Service packs AEM 6.4.8 and AEM 6.5.4 include this feature. To enable this feature, set the OSGI configuration properties storeSAMLResponse=false and handleLogout=false and it would not store the SAML response.
We are developing an application having many screens. Each screen data is coming from Rest API. What the best practice to store the session data(screen data) at backed?
For example- I need data of screen two(includes the screen input data and response from rest API) in 4th screen. For this I want to store the rest response of screen two in server side.
I came of with two scenarios for this, if anyone has experience please help:
1) Session management using REDIS-- but this is mostly used in clustering environment.
2) Session management using spring security and spring session management.
Please suggest the better way of doing it.
Details:
Spring-boot application will be hosted in cloud
Also the question is not related to security, authentication, authorization.
Kindly help me with best practice to move the data to different screens.
For example- I need data of screen two(includes the screen input data and response from rest API) in 4th screen. For this I want to store the rest response of screen two in server side.
What you are describing there is a violation of the Stateless architectural constraint of REST.
The "right" answer is to take one of two approaches; one is to store the "session data" on the client -- the server sends the data back to the client (for example, as fixed/hidden fields in the form) in the response. The other is to use the client actions to modify a resource (think shopping cart).
The core problem is this: the stateless constraint means that the server is only operating on the current request; the server only ever sees requests, not state changes (ex: the client can hit the back button, or otherwise jump to some other state in its history, or fetch additional state from somewhere else).
If you use the "modify a resource" approach, you may want to review RFC 7232: Conditional Requests, and think about whether or not your use case needs to worry about the "lost update problem".
We have a workflow based application where a given process move from one state to another state based on User action.Currently our requirement is to have UI displayed its current state and allow user to take next action steps.So my question is does generally server tells UI the next actions that can be taken or the UI should decide based on current action? This application is designed using RESTful webservices.
The server should provide the client the next allowed actions, also known as state transfers, using links. Those links should, at least, contain two pieces of information: URL and relationship. The relationship tells the client the meaning of the state transition, allowing to recognize what it will do. The URL only says where to locate the service.
Typically, a REST web service should be ignorant of client state. It should only provide the ability to retrieve and update data based on a specific url (you may want to read up on REST). If you are following these guidelines, then the UI should drive any logic regarding the state of a workflow or record.
The hypertext returned provides the next "possible" transitions in the form of 'links' to the "resources". The client/user selects the next transition.
REST APIs must be hypertext-driven may be a good read!
We have a GWT based thick client like web application. The application is considerably large and has some initial load time.
We would like to send the users of our application e-mail messages with href links that would open up a specific asset in our application. Well this of course has the effect that clicking the link opens up the application again, reloads it which we would like to avoid. Ideally we would like the href link to just signal our application/web page somehow so that we could pick up the event in our application and react to it.
Any ideas how we should approach this or is this even possible ?
Thanks!
You need to use a GWT Hyperlink which is a widget that serves as an "internal" hyperlink. That is, it is a link to another state of the running application. When clicked, it will create a new history frame using History.newItem(java.lang.String), but without reloading the page.
If you are not already using it, information is here on GWT's History mechanism
There seems not to be any elegant solution to send an event from a link to an existing browser window. Few solutions I have encountered this far:
a) Implement a cookie polling solution for the application to poll if a cookie exists or changes. The link points to our server which just sets the cookie and this way informs the running app about the event. Some tricky handling should be implemented with some kind of 2-way protocol between the returned temporary page from server to handle the situation where the application is not (yet) running.
b) The same approach as in solution a) but use html5 local storage for communication. This way the poller is not needed as the local storage fires an event when content changes. This would be a possible solution but is not for me as we have to support older browsers without local storage support.
c) A long polling ajax or a web socket for delivering events from the server to the client. A solution but seems overkill and might require a modern browser for atleast web sockets.
We have a working web application, which has been developed with ExtJS for client side, and Struts, Spring, Hibernate for server side. now, we are considering to migrate to GXT (or may be GWT itself). The thing is I'm very new to GWT/GXT. and we are trying to decide whether we go down this road or not.
1) Until now, we have 2 domains for our web-app. one is that the application (Struts+...) have been deployed to, and the other is mainly a cookie-less custom CDN. The transfer between client and server is mostly XHR requests, sending/receiving JSON and/or JSONP. But with the new approach ahead of us, I began to understand that we are supposed to have only ONE domain, for the whole GXT application. Is it correct or I forgot to consider something here?
and if not, Is it possible that we deployed just part of the application (i.e. com.ourcompany.webapp.gxt.server.*) to the main server, and the contents that have been compiled and generated by the GWT compiler to the other CDN-like domain?
2) The other big issue we are facing is that the current application is consists of mostly 3 huge modules. One is responsible for "SignIn", the other is for "Webtop", and the third one is "Modules which each users has access to". The latter has been generated on the server due to "access rights" of each users, and obviously could be different from one user to the other.
The only thing I could find on this matter, which might be related is Code Splitting. Although I'm not totally sure if this would be the right solution for this.
We want that the application, on Start Up, checks whether user has been logged in or not. if not, loads the SignIn sets of javascript files (i.e webapp.signin.nocache.js), then after user has entered the correct username/password, unloads this signin file and loads webtop.nocache.js AND modules.nocache.js.
I would be really appreciated if you could help me out.
1) If your GWT app is loaded from a different domain than you have to face the same origin policy. You can not do a xhr to a different domain. You could use the ScriptTagProxy to get around this. But it does not feel very netural.
2) You can use CodeSplitting in order to automatically load a particular part of your application dynamically. All you have to do is to warp your splitt point into an async call.
A detailed compile report gives you a pretty good overview how well code splitting is working.
But CodeSplitting does not unload already loaded code. If its really importend to do so you have to redirect the user to another url in order to load the appropriate user depended module.
Once Javascript code has been loaded and executed its impossible to remove the code from the browsers memory.
Grettings,
Peter