Hi,
I modified my header with a link that opens another URL. The thing is that the URL varies depending on the environment (prod, test, dev) so I want to set the url dynamically depending on the context.
Simple window.location.hostname does not work. And I had no luck finding any hint in the documentation. Looks like the header script runs in some different context than the browser but I can't figure out how to get to the url value that is in the browser.
So can you advice me on how to get the hostname so that I can collect url that would look like this:
"https://" + someFunctionThatGetsTheHostname + ":8443" ...
My code:
function getTicket() { var myTicket = ""; var result = remote.call("/custom/ticket"); if (result.status == 200) { var myTicket = eval('(' + result + ')').ticket; } return myTicket; } model.jsonModel = { widgets: [{ id: "DOC_FILTER_PAGE_TITLE", name: "alfresco/header/SetTitle", config: { title: "XY" } }, { id: "DOC_FILTER_HORIZONTAL_WIDGET_LAYOUT", name: "alfresco/layout/HorizontalWidgets", config: { widgetWidth: 100, widgets: [ { id: "DOC_FILTER_IFRAME", name: "alfresco/integration/IFrame", config: { src: "https://" + window.location.hostname + ":8443/" + getTicket(), srcType: "FULL_PATH", height: "800", width: "100%" } } ] } }] };
Solved! Go to Solution.
a) There is typically no need to get the host name on the server side since all links / references should be relative, or at most absolute to the root of the host, which will be prepended by the host. The server should not have to deal with the host name, which might be completely different than what the browser called anyway due to proxying or other forwarding / URL rewriting mechanisms.
b) When you need environment specific URLs / host names (or any other sort of configuration / state), using the Surf configuration mechanism would provide a clean way of handling this without resorting to any host name guessing mechanics. Configuration is defined in share-config.xml / share-config-custom.xml (e.g. repository-url for Share to create WebDAV links) and can be retrieved in server-side JS code like this. There technically is no schema at all for the share-config.xml, so you can define whatever sub-elements you like to a custom config section of your own. The main differentiation is made via the "condition" on the <config> element which is the entrypoint to a so called "config section".
Hi Eddie,
I did and although I agree that writing something like this might help me with solving this, it seems to me like killing a mosquito with a bazooka .
Considering how simple it is to get the hostname with javascript when it runs in the browser context, it's hard for me to believe that there is no API in the Share tier that could do the same for me.
Isn't there a way (API) how I can talk for example from page context (or other part of the Share) to the browser?
a) There is typically no need to get the host name on the server side since all links / references should be relative, or at most absolute to the root of the host, which will be prepended by the host. The server should not have to deal with the host name, which might be completely different than what the browser called anyway due to proxying or other forwarding / URL rewriting mechanisms.
b) When you need environment specific URLs / host names (or any other sort of configuration / state), using the Surf configuration mechanism would provide a clean way of handling this without resorting to any host name guessing mechanics. Configuration is defined in share-config.xml / share-config-custom.xml (e.g. repository-url for Share to create WebDAV links) and can be retrieved in server-side JS code like this. There technically is no schema at all for the share-config.xml, so you can define whatever sub-elements you like to a custom config section of your own. The main differentiation is made via the "condition" on the <config> element which is the entrypoint to a so called "config section".
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.