Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for cross-domain Apps #270

Closed
timburcham opened this issue Mar 16, 2016 · 7 comments
Closed

Add support for cross-domain Apps #270

timburcham opened this issue Mar 16, 2016 · 7 comments

Comments

@timburcham
Copy link
Contributor

When working with apps loaded cross-domain into a container, one of the common challenges encountered is that any relative paths in the app are executed in the scope of the container, and cannot be found. It would be great to see an addition to perhaps context, or the overall manifest of an app, allowing the app to declare its own FQDN, such that the app itself could later reference this parameter, and make appropriate requests for additional assets or JSON data.

The only known workaround for this at present is to hardcode FQDNs into the apps themselves, which is less than ideal from a build pipeline and deployment pov.

Reference example on a possible solution (see appBaseUrl param listed below):

{
 "name" : "My App",
 "appId" : "com_myfirm_myapp",
 "description" : "My Awesome App",
 "manifestUrl" : "http://myawesomeapp.com/apps/com_myfirm_myapps.js",
 "context" : { "myParam" : true },
 "appBaseUrl" : "http://myawesomeapp.com"
}
@timburcham
Copy link
Contributor Author

Alternately, '//myawesomeapp.com' for a protocol-less request

@brianbaker
Copy link
Member

similar to #73 ?

@qrider
Copy link
Contributor

qrider commented Mar 17, 2016

Looks like #73 is tagged with version2. I could be wrong, but I don't think this would necessarily be a breaking change.

@timburcham
Copy link
Contributor Author

Happy to close this if it's a duplicate, but agree with @qrider on this not being a breaking change, necessarily. Sounds like @qrider is looking at cleaning up roadmap, perhaps that pulls #73 out of 2.0 and into a sooner version.

@brianbaker
Copy link
Member

I think maybe the reasoning for #73 being pushed to 2.0 was because 2.0 was going to go the AMD route which already has some functionality similar to this.

@timburcham
Copy link
Contributor Author

Specifically for this issue (slightly different from #73), here is some pseudo and real code from my own testing that will support this. I'm doing this in a local example where I'm simply modifying the manifest request before it's sent:

if (F2.isLocalRequest(a.manifestUrl)) {
    console.log('local');
} else {
    var baseUrl = '';
    var urlTokens = a.manifestUrl.split('//');
    if (urlTokens.length > 1) {
        console.log(urlTokens);
        var baseUrlTokens = urlTokens[1].split('/');

        if (baseUrlTokens.length > 0) {
            baseUrl = '//' + baseUrlTokens[0];
        }
    }

    a.manifestBaseUrl = baseUrl;

    console.log('c_', a);
}

In turn, you can then reference this Url in the app's requests which would otherwise be hardcoded or relative:

$.ajax({
    url: this.appConfig.manifestBaseUrl + '/data-apis/storage/getWatchlist',
    type: 'GET',
    context: this
}).done(function(response, status) {
//

@brianbaker
Copy link
Member

close in favor of #73

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants