As per the GWT docs, there are two ways two internationalize my GWT app. One is, declare the language in the HTML itself (hardcoding) through meta tags, another is to use a query param in the URL (like &locale=de).
My webapp is dynamic,different users from different locales will be using it, so the first option is not viable. The 2nd option is fine, but somehow, appending query params to a URL is my pet peeve. I tried to make it dynamic by doing something like $("head).append("<meta name='gwt:property' content='locale=de'>"); first thing on onModuleLoad, it doesn't work.
My app will actually be a redirection, some other web-page will contain a redirection like foo.com&locale=de. Based on that, it will load the required locale fine. But after that, I want to reload it again without showing the query param in the URL, taking the locale information from cookies which can be set in the first load. Is it possible to do so?
There is a third option using cookie.
Reference - GWT Internationalization for dynamically generated content
Ensure you set locale value to the cookie or have a default value for your cookie before user chooses his locale. In our case user chooses a language before login ( where i set the cookie locale value for the user) and read this into the gwt application on load.
Adding the parameter to a model (in a Controller) and picking it up on the client (in a *.jsp) will work for you?
<meta name="gwt:property" content="locale=${locale}">
Then you just need to refresh the page and reset the locale value in a controller. Add the meta-tag code in your html/jsp page, it should be there prior to page loading.
onModuleLoad works with code already loaded to the browser window, so appending meta after loading will not work.
Related
I am hosting a flutter web app, which involves the initial url having query parameters (e.g. https://mysite.web.app/?k=ZF6K5UA7X3Jk9HJanla3). I use the url_strategy package to get rid of the #, however when the site loads, the query params are stripped off, leaving the bare-boned "https://mysite.web.app". I have got around the functionality aspect by storing the param as a cookie variable, however it is not ideal.
Is there any way to re-instate the params programmatically in the url bar of the browser? The reason for this is for both (i) giving the user the option to share the original URL, and (ii) allow them to add the app to their mobile device screen as a PWA (with the original full url).
Any suggestions welcomed.
I resolved this via the implementation of go_router. With the combination of state.queryParams and Router.neglect(context, () => context.go('/?k=$myOriginalParam')) (from any pages that wanted to go back to the original route with no browser back button history), I can retain the query parameter in the browser bar successfully.
I am not a developer but I need help talking to my web developer. We have a company website with staff profiles made with TYPO3. On each profile site, we want to embed an URL to a repository website, which will show a list of the person's publications. The URL encodes a SOLR search string for this repository. So, the URL is the same for all staff profiles except for a personal identifier somewhere in the middle. Instead of typing the complete URL into every staff profile page, I would prefer to have a URL constructed with placeholders like this
placeholderA+staffID+placeholderB
In case the SOLR search string changes in the future (i.e. excluding certain document types in this search or changing the sorting) we would have to change only the placeholders, not the complete URL in each and every profile page. There has to be a simple way to do this, but my web developer tells me this would require a database with the staff IDs and a lot of scripting. Is she right? Since we have to touch every profile page to include the URL initially, it would be ok to enter and store the unique staff identifier on each profile page. I just want to avoid touching each page again when changes are required.
It is such a useful concept, there has to be a plugin or something to do this already. Can you throw me some keywords or hints for our next discussion?
How is your URl build?
in general URLs are build in multiple parts
[[[<protocol>]<domain>]<path>[?<parameters>]][#<anchor>]
Now we need to identify where you want to insert the staffID:
is it in <path> or in <parameter>?
In TYPO3 we don't have a real <path>. It's just an image to hide the basic URL index.php with some parameters. first of all the parameter &id=123.
further parameter can occur as parameter or as path segments. Anyway TYPO3 will handle a translation between virtual path and parameters (either an extension like realurl or the core). For URL generation you call TYPO3 providing a list of parameters, or if a 'page' is called you will end with a list of parameters which will decide the rendering.
Then you can mixup the URL generation:
You take a generated URL and add path segments as you 'guess' them, without involving TYPO3. This might result in problems as you will call the server with an url TYPO3 does not know about as it has not generated it. If TYPO3 generates an URL it stores it in the database with the 'translation' into parameters.
realurl can guess the translation, but sometimes it failes, especially if chashes are used.
What are cHashes?
with cHashes TYPO3 secures the page cache against unrelated parameters. If a page is generated it depends on the parameters. Any further parameter might result in another page, so TYPO3 stores a hash of the parameters with each cached page. For verification this hash can be added to the URL. this additional parameter also is stored in the 'translation' table.
If you now add parameters to an URL which is stored and it gets translated back to parameters you have an cHash parameter which identifies the cached page. But only for a part of the parameters. your added parameters were not known and not considered when the page was generated and stored in cache. If the cached page is delivered your additional parameters are 'lost'.
So it is necessary to include all parameters in URL generation with TYPO3.
Your adding of the staffID must be done with TYPO3 and can't be an concatenation of path segments in the HTML templates (or javascript).
If you later on change your parameters you need to change the generation of your URLs.
I would recommend to add the staffID as a field to the record and generate the URL to the document list with TYPO3.
I'm just new to Zend Framework. Currently what I'm trying to do is when user access my website
they will first see a select box with two language such as english and germany to choose.
Only when they make a selection, the browser will redirect them to the index controller of that specific language page.
So my question is how to make a select box in bootstrap file or any kind of possible ways to do that and how to redirect user after that? Any solution will be much appreciated!
Don't ever use bootstrap file (and I'm talking about both Bootstrap.php and index.php) for this kind of operations. First, it just won't work the way you ask; second, you'll mess your app's structure big time.
Instead you may use one of the following approaches:
1) add some predispatch hook that will check whether the choice has already been made by checking the user's cookies. If it is, proceed with request as usual (probably setting some Zend_Registry lang variable to be used later), if not, redirect for the language choosing page; the latter should store the choice made in cookies.
2) implement a simple rule in your Router/mod_rewrite: when the requested URL contains 'the language part' (http://example.com/lang/xx/... or just http://example.com/xx/...), it automatically uses this part so set the lang param. If not, the request is automatically redirected to the language choosing page. The latter, in turn, leads the user to a language-specific page, where all the links are made language-specific.
The latter approach is inferior, in my opinion, as user will have to use a language-tuned gateway all the time. But you don't have to store this info in cookies.
You could make a plugin that use the preDispatch event to look if the language has been chosen (e.g stored in cookie or session) and redirect to the landing page if not.
Look here zend framework plug-in - predispatch()
and the ZF's action plugin documentation.
That's what I do to force login in my app.
Now in your position what I would really do would be detecting the language of the user with a fallback to English and a switch widget somewhere in your navbar.
As per the Authentication Documentation, I'm directing my user's to the following URL to initiate the authentication flow:
https://www.facebook.com/dialog/oauth?client_id=251747341532139&redirect_uri=https://www.facebook.com/connect/login_success.html
However, instead of the login page looking like:
... (i.e. like it does in the documentation and in other Apps I've created and used), it looks like this...
Does anyone know why?
I've tracked the redirects that the page makes, and it's as follows:
https://www.facebook.com/dialog/oauth?client_id=251747341532139&redirect_uri=https://www.facebook.com/connect/login_success.html
https://www.facebook.com/connect/uiserver.php?app_id=251747341532139&method=permissions.request&display=page&next=https://www.facebook.com/connect/login_success.html&response_type=code&fbconnect=1
https://www.facebook.com/login.php?api_key=251747341532139&skip_api_login=1&display=page&cancel_url=https://www.facebook.com/connect/login_success.html?error_reason=user_denied&error=access_denied&error_description=The+user+denied+your+request.&fbconnect=1&next=https://www.facebook.com/connect/uiserver.php?method=permissions.request&app_id=251747341532139&display=page&redirect_uri=https%253A%252F%252Fwww.facebook.com%252Fconnect%252Flogin_success.html&response_type=code&fbconnect=1&from_login=1&rcount=1
Application type is set to Native/Desktop, and I've set the App Integration to "Website".
If the language I'm using makes any difference, I'm using C#, and setting the Url of System.Windows.Form.WebBrowser.
As per the above comments, you can use the display parameter in the URL to control which kind of dialog to show, as you would normally do with the JS SDK.
Your URL becomes:
https://www.facebook.com/dialog/oauth?client_id=xx&redirect_uri=yy&display=popup
Is there a way to disable the caching of html pages in the browser with GWT ?
I'd rather avoid using inserting META HTTP-EQUIV="EXPIRES" CONTENT=... in the header of my html pages, and do it programmatically instead - if possible.
I'd be surprised, if this is possible (and has any effect) with GWT/JavaScript, because it would mean, that the question if and how long the page will be cached can change dynamically while the user views the page.
But even if it is, it won't work with proxies, because they don't evaluate JavaScript... The same is true for your web server, which should serve the page with that HTTP header.
So if you want to make your caching http-equiv meta tags dynamic, you should probably do that on the application server: Use a Servlet or any dynamic page (could even be PHP, if you want) to generate the HTML page. You could even set the real HTTP header there (e.g. in a Servlet by using HttpServletResponse.setHeader(String name, String value))
i would say you can't.
however, you can use tricks to always refresh your application by adding parameters on links, for example the URL to your app. a changed parameter is considered as a not-yet-fetched page
so try something like that:
<script type="text/javascript">
document.write("<"+"script src='client/client.nocache.js?today=" + getTime() + "'><"+"/script>");
</script>