As far as I know, UI5 determines the wanted localization based on browser's HTTP header accept-language with respect of supportedLocales and fallbackLocale values of the manifest.json app descriptor.
In my case, however, initially user sees an authorization dialog in English and after authorization I would like set an app localization based on a user config, loaded upon successful authorization.
Based on Language switch in SAPUI5, I've tried to apply:
sap.ui.getCore().getConfiguration().setLanguage("fr");
in the view onInit() but instead I get a blinked view in the desired localization and then an empty window.
Since sap.ui.getCore().setLanguage() does not guarantee that already created, language dependent objects will be updated by this call, I've tried location.reload(); to trigger a complete page reloading and rebuilding all UI5 elements but it doesn't help.
I'm not sure if this can be done without a reload.
For modern browsers, you can use this code to change the URL:
const oURL = new URL(window.location.href);
window.location.href = oURL.searchParams.set("sap-ui-language", "en").toString();
If, for some reasons, you have the language already in the URL, you need to add a cachebreaker.
My go-to choice is
sap.ui.getCore().getConfiguration().applySettings({
language: 'de',
});
This switches the used i18n bundle.
However, there are still some occurrences that don't get translated e.g. the work-day labels in a sap.m.PlanningCalendar, which remain in the browser's language.
Related
I'm using FlowRouter. If I start on the homepage everything works well. I can work through the routes (change the pages) without problem. However, if I hit refresh in the browser, I get a series of errors. My url looks like this:
/story/586d536e34821281735b53a4
The ID is being returned in console under the following method:
Tracker.nonreactive(function(){
I think the subscription is being completed, so I'm a little confused as to why reloading a url is different than loading from the home page.
What am I not understanding here?
Reloading a url will make a HTTP request to server to get all the application source. Whereas navigating to a route from another one does not make any HTTP requests to get the application source because they are already available (they were loaded from the previous route), in this case the router will just get the appropriate content and render on the page. This is normal behaviour for Meteor apps and all other single-page apps
The error you encounter is because your data is not yet available on client, to fix it you could simple use a placeholder if the value is undefined.
I need to integrate Google's identitytoolkit (Google's identitytoolkit) with my Google webtoolkit (GWT) application.
However rendering the gitkit signInButton or widget is already not straightforward because the way to do it is linked to "window.onload". And I need to render the widget at a later moment.
I managed to do it (see below), but I am not happy with this and I wonder if someone else found a better way of integration.
private native void showGitKitWidget() /*-{
$wnd.google.identitytoolkit.signInButton(
'#gitkitDivId', // accepts any CSS selector
{
widgetUrl: "//127.0.0.1:8888/gitkit/signin.html",
signOutUrl: "/gitkit/signout",
popupMode: true
}
);
var evt = $doc.createEvent('Event');
evt.initEvent('load', false, false);
$wnd.dispatchEvent(evt);
}-*/;
Update
Actually using the popupMode parameter for the signInButton makes a seamless integration even closer. This lets the widget popup in a browser window and leaving the GWT window unchanged. Then in the widget instead of redirecting to the successUrl I use the JS callback to trigger an AJAX call instead.
var config = {
idps: ["googleplus"],
signInSuccessUrl: '//127.0.0.1:8888/gwt/servlet/gitkit/signedin',
callbacks: {
signInSuccess: function(tokenString, accountInfo,
opt_signInSuccessUrl) {
/* !!! Tell GWT parent window that we are ready...
I believe using a cookie for which the parent is
regularly looking is the way to go, because it
will work in mobile browsers too.
*/
return false; // prevents redirect to signInSuccessUrl
}
}
Update Finally the GWT parent window will wait for the result cookie and if found make the AJAX call to the signInSuccessUrl. It will also have to render the signInButton again, which will then show the signed in user.
So the only ugly workaround is how the signInButton is rendered using the onload method call.
It would be very helpful if there would be a way to render the signInButton dynamically when needed, for instance if there were a "$wnd.google.identitytoolkit.update()" method. This could be called any time for the first time and should also be able to handle signin-status change!
In conclusion, I have answered my own question, which might be helpful to others, but also I would still like to ask if there would be a better way, which I missed.
As you've noted, the Identity Toolkit widget currently needs to be triggered by page load. Single-page applications (like those built with GWT) should place the widget on a separate page. Then you can redirect the user there - or render via popup, as you've noted - to sign in the user in.
If rendering the sign-in button is a problem, there is documentation on how to load the widget directly.
In my Vaadin webapp I have a tipical architecture with login. In some cases, the user can access directly to some resources using Vaadin URI Fragments (http://example.com/#fragment).
When a user tryes to access some resource, If the user has logged in, I take from the URL the #FRAGMENT and I bring him to it.
But if the user has no logged in, when he logs in I used to bring him to the main page using
getPage().open("/", "_self");
but since if I add an URI Fragment, the getPage().open(...) does not work.
Is there any way to redirect the user to a correct URL (URL with UriFragment in my case) from code?
Note that there is a fundamental difference in how navigation is handled in traditional web applications versus single-page applications as implemented with Vaadin. In traditional web applications you navigate through the app by making full HTTP GET-Requests on some path (such as www.example.com/myapp/home). On each such request, a full page reload is performed. You can't do that with Vaadin, as a full page reload means reloading the Vaadin widget set and rebuilding the page layout from the ground up. Therefore, single-page applications typically use the URI fragment for navigation purposes. Changes to this fragment are solely handled by the client-side JavaScript code. There will be no GET-Request induced by the browser when the URI fragment is changed.
That's why the approach you described doesn't work for you. Using Page.open(...) will open a web page through a HTTP GET-Request resulting in a complete reload of your Vaadin application.
The solution for your problem is to solely handle all navigation (including state-dependent redirects) through the Page object's URI fragment handling methods (or through the [Navigator][1] component). Redirecting in Vaadin can be achieved by programmatically setting the URI fragment with Page#setUriFragment() or Navigator#navigateTo() and having your URI handling code (or Navigator) take care of the rest. Only then it is assured that your users stay on the same page even when they are redirected to a login form or to some other place after logging in.
I would like to add to Roland's answer and share how I solved this.
My UI:
#Override
protected void init(VaadinRequest request) {
setSizeFull();
setContent(masterView);
getPage().addUriFragmentChangedListener(event -> present(event.getUriFragment()));
present(getPage().getUriFragment());
}
The masterView is just a CustomComponent that has a content section. When the menu is clicked, I simply setContent to the masterView's content section. Swapping out the middle, basically.
present method:
private void present(String fragment) {
masterView.setContent(getComponentFromFragment(fragment));
}
Finally:
private Component getComponentFromFragment(String fragment) {
if (fragment.equals(someOtherView.NAME))
return someOtherView;
return null; // null clears it out as in the welcome page
}
The important part is the present in the init. When the UI renders for the first time and fires the init, it goes ahead and grabs whatever the URI fragment is in the browser and presents that as well.
Works great.
Maybe this can work:
UI.getCurrent().getPage().executeJavaScript("window.location.href = 'http://google.com'");
I have two questions:
Q: 1
I'm currently developing a GWT app. The entry point for the app is: ImageViewer.java. I could well access it by http://127.0.0.1:8888/ImageViewer.html?gwt.codesvr=127.0.0.1:9997. I have a service called "Search" which has corresponding "Async" and "Impl"'s defined. Now, I call the service from client side, using RPC. I could call the service, obtain return value. Everything works fine.
However, I expect the application to show a behavioral change on URL. i.e. when a service is being accessed, I thought it would be reflected on the browser's URL something like: http://127.0.0.1:8888/search?gwt.codesvr=127.0.0.1:9997 as I've modified web.xml. However, this behavior is not realized. Any particular reason why this is not reflected??
Q:2
This one is a reverse of the previous ques. i.e. I have an application running. Let's say it has an entrypoint class(Imageviewer.java) and another composite class (searchClass.java) which would be loaded on the Imageviewer based on an event. This searchClass invokes the "search" service mentioned in the previous question.
I could load the "searchClass" in "Imageviewer", invoke the service, and the service also returns the value needed. Everything works fine... But,
I need something like this: by just typing this query string:
http://127.0.0.1:8888/search?value=John
I want the "searchClass" to be loaded on the "ImageViewer", call the service using the value(which is "john" in this case) and display the result. Is this possible at all?
what I've tried: I have tried to create a httpServletClass on the server and mapped it with the URL and could do the search. The search returns appropriate results. However, I want the results from the server to be displayed on the client. Remember, I'm directly using a servlet to read the URL and so there is no value being passed from client to server.
Thanks in advance.
A: 1. To change URL, the hash part, you need to set new history token in the History class. More about history management in this article.
A: 2. For the second part you could achieve it by changing the history token, for instance "http://127.0.0.1/search#value=John". The history service will trigger an event if the # part changes. You could also use the part with "?", as in your example, if you use Window.Location , but it will cause reload of the application, which would put the whole idea of using GWT in question.
RPC (AJAX) calls are done Via XHR and do not change the browser URL.
You can't (with the URL you presented). GWT apps normally run in one web page, i.e. the URL does not change (see how gmail changes browser url bar). What you can do is enable GWT history support. Then your url would be http://host/#search?value=queryu
I'm wondering if you could suggest me any way to implement "user roles" in GWT applications. I would like to implement a GWT application where users log in and are assigned "roles". Based on their role, they would be able to see and use different application areas.
Here are two possible solution I thought:
1) A possible solution could be to make an RPC call to the server during onModuleLoad. This RPC call would generate the necessary Widgets and/or place them on a panel and then return this panel to the client end.
2) Another possible solution could be to make an RPC call on login retrieving from server users roles and inspecting them to see what the user can do.
What do you think about?
Thank you very much in advance for your help!
Another way is to host your GWT app in a JSP page. Your JSP might contain a snippet of code like this
<script type="text/javascript">
var role = unescape("${role}");
</script>
Where ${role} is expression language expanded from value you computed from the associated servlet / controller and exposed to the JSP.
When your GWT app runs in the browser, the value will be filled out. Your GWT app can easily call out into JS to obtain this value from a native method call, e.g.
public native String getRole() { /*-{ return $wnd.role; }-*/;
So your module could invoke getRole(), test the value and do what it likes to hide / show elements.
Obviously your backend should also enforce the role (e.g. by storing it in the session and testing it where appropriate) since someone could run the page through a JS debugger, setting breakpoint or similar that modifies the value before it is evaluated allowing them to access things they shouldn't be accessing.
Following scenario works for me:
GWT app is behind security constraint.
On module load I make RPC call to retrieve roles from the container. I store them in main GWT module's class as static field, to make it easy for other classes to use it.
Each widget (especially menu) can use roles (e.g. call Main.getRoles()) and construct itself according to roles. I don't pass roles in constructor. Each widget knows how to behave depending on role.
If it's crucial to not only hide things but also enforce them you can use container security and check roles and rights while invoking business methods.
While using GIN you can also create singleton class to store roles retrieved during login and inject it wherever you need it.