Opened 7 years ago

Closed 7 years ago

#14612 closed defect (invalid)

OpenSocial gadgets using dojo cannot use dojo/xhr to do xhr.

Reported by: ddumont Owned by: ddumont
Priority: high Milestone: 1.8
Component: IO Version: 1.7.1
Keywords: Cc: Bryan Forbes, Adam Peller
Blocked By: Blocking:

Description

In an Open Social gadget environment, gadget are encouraged to use Open Social apis to do xhr. Part of the reasoning for this, is gadgets are often isolated in iframes served from the Open Social server. This causes issues when gadget applications try to use dojo/xhr to load files from a server, as SOP interferes with nearly any request they wish to make.

The Open Social apis allow for XHR by utilizing proxies that exist on the Open Social server.

I will be posting a patch through a dojo contributer here at IBM shortly that implements an XmlHttpRequest? object for dojo/xhr to use that will translate a dojo/xhr to use the Open Social apis, if they are found. Hopefully existing dojo applications will work without any refactoring.

Attachments (1)

xhr.patch (4.1 KB) - added by Adam Peller 7 years ago.
Patch from Dan Dumont (IBM, CCLA)

Download all attachments as: .zip

Change History (12)

comment:1 Changed 7 years ago by ben hockey

curious to see how it would compare to using dojox.io.xhrPlugins.

Changed 7 years ago by Adam Peller

Attachment: xhr.patch added

Patch from Dan Dumont (IBM, CCLA)

comment:2 Changed 7 years ago by Adam Peller

Cc: Bryan Forbes added

comment:3 Changed 7 years ago by ddumont

dojox.io.xhrWindowNamePlugin looks interesting, but I'm not seeing much doc on it. Generally, the OpenSocial? spec encourages gadgets to use the OpenSocial? libraries for xhr. It would be nice for applications previously written against dojo apis to work as-is.

The change here is roped off with a has feature. I can move the code out into another module loaded conditionally by xhr if that makes the patch more acceptable.

comment:4 Changed 7 years ago by bill

Wow, that is a lot of code to add to a base module. Also, the change is a little stale, I've moved the feature testing into dojo/sniff.js, so your patch won't merge.

comment:5 Changed 7 years ago by ben hockey

i had been wondering if we should be looking for a way to make it simple to swap out the implementation for xhr (probably something for 2.0). for example, you might want to run some tests using server side javascript where you might not have an XHR object but another module might be able to provide the interface that is provided by dojo/xhr. open social would just be another provider.

my thoughts were that it might be possible to have the high level abstraction be called dojo/http or something similar and then throughout dojo (and in applications) use dojo/http rather than dojo/xhr. after all, it's probably more correct (at least throughout dojo) that we really just want to make an http request and we don't care if it was done via xhr or some other means. we've just called it xhr because that was all we have available to us in the browser.

we would then have some mechanism that allowed the dojo/http interface to be implemented via different providers - dojo/xhr would be one of these providers, and then we could have the opensocial provider and the node-http provider, ...

its something i've been wondering for a while and this ticket prompted the thought again.

comment:6 Changed 7 years ago by ben hockey

ps - i guess the mechanism for which provider should be selected would be similar to how dojo/query uses different selector engines.

comment:7 Changed 7 years ago by Adam Peller

What are the implications for a monkey-patch until 2.0, where dojo._xhrObj must be assigned? We still have a top-level dojo.* reference here

comment:8 Changed 7 years ago by ddumont

I'm no fan of monkey-patches.

I can rework the patch. For now, if it eases the concerns of bill and neonstalwart, I can move the code into a new module file that is conditionally included based on the has feature in sniff.

Would that address all concerns until 2.0 can do something like what neonstalwart suggested?

comment:9 Changed 7 years ago by bill

A new dojo/html module could go in before 2.0. Although it does sound like something you'd want to coordinate with Bryan (see http://thread.gmane.org/gmane.comp.web.dojo.devel/16600/focus=16600)

comment:10 Changed 7 years ago by bill

Cc: Adam Peller added
Component: CoreIO
Owner: set to ddumont
Status: newpending

It sounds like this should be handled through a special provider registered with the dojo/request code. Not sure where that plugin should go -- dojo, dojox, or more likely in OpenSocial itself -- in which case we can just close this ticket as wontfix. @ddumont can you handle this outside of dojo now?

comment:11 Changed 7 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

Note: See TracTickets for help on using tickets.