Using umbRequestHelper getApiUrl with package specific urls
I wan't to replace my hardcoded urls in my angular services with something more dynamic and found the our article on Server variables & URLs
I've added a new eventhandler and implemented the Parsing method with the custom routes and to a dictionary item with the name of my package.
dictionary.Add("package_name", new Dictionary<string, object>
{
{"Api", "url"}
});
When calling the Umbraco.Sys.ServerVariables["package_name"] the added variables show up.
I was hoping I could use umbRequestHelper.getApiUrl to retrieve the urls, in my angular code, but after looking in the source code I see the getApiUrl is hardcoded to only look in Umbraco.Sys.ServerVariables["umbracoUrls"].
So my question is, what is the correct way to have umbRequestHelper look for my custom routes in Umbraco.Sys.ServerVariables["package_name"]?
For now I've added my own service with a literal copy of getApiUrl that looks in the custom Umbraco.Sys.ServerVariables["package_name"], so my code works but it feels hacky.
Using umbRequestHelper getApiUrl with package specific urls
I wan't to replace my hardcoded urls in my angular services with something more dynamic and found the our article on Server variables & URLs
I've added a new eventhandler and implemented the Parsing method with the custom routes and to a dictionary item with the name of my package.
When calling the
Umbraco.Sys.ServerVariables["package_name"]
the added variables show up.I was hoping I could use
umbRequestHelper.getApiUrl
to retrieve the urls, in my angular code, but after looking in the source code I see thegetApiUrl
is hardcoded to only look inUmbraco.Sys.ServerVariables["umbracoUrls"]
.So my question is, what is the correct way to have
umbRequestHelper
look for my custom routes inUmbraco.Sys.ServerVariables["package_name"]
?For now I've added my own service with a literal copy of
getApiUrl
that looks in the customUmbraco.Sys.ServerVariables["package_name"]
, so my code works but it feels hacky.I’ve done it the same way.
Haven’t seen a more elegant solution.
is working on a reply...