So XHR patch the browser directly ( but do it without using the File API )
I think is the best approach.
It is not hard, not at all, that is/was my point.
The fact that the file is cordova_plugin.json means that it MUST be loaded
by XHR, where if it was cordova_plugin.js it could just be added as
Hey Jesse,
For WP7+8, if XHR relies on some cordova APIs, I think those APIs need to
be loaded as special-cases for windows phone, I.e. Integrate those bits
before onNativeReady fires in cordova-js. This way the plugin loading code
can happen as-is and can rely on XHR safely.
It'd be good to see
On Wed, May 15, 2013 at 4:48 PM, Jesse wrote:
> 3) tired of being the curmudgeon on the list, but why do we keep making
> things more and more complicated?
>
I wish I knew the answer to this question too.
I have replied on the jira issue.
There are still numerous outstanding things with this piece of code.
1) it cannot use other APIs because it all happens before deviceready, XHR
to local files requires the FileAPI on WP7 + 8
2) still waiting to hear on the timing differences compared with script t
Just had a chat with Fil and learned that we did not have automatic js
installation until braden implemented this. So disregard my last post.
I am reviewing some of our old threads on this issue. If anyone else is
interested, You can view [1]
[1]
http://apache.markmail.org/message/vxmd3yrr5i5q27w
This may be unpopular, but I'm wondering if the best solution might be to
drop jsmodule/cordova_plugins.json and go back to just including script
tags in plugin.xml that get added to your index.html/cordova.js. I know it
isn't as pretty, but it won't have to deal with these issues.
On Wed, May
That won't work for remotely hosted pages and wouldn't allow for the File
API to be pulled out into a plugin.
Based on the constraints, the only other solution I can think of is to
require that cordova.js sits at the root of the project. The plugin loader
scripts could then figure out the path bas
Could we leverage our own File API to load the plugins json instead of
relying on (possibly unclear local vs remote) XHR semantics?
On 5/15/13 12:03 PM, "Steven Gill" wrote:
>Hey All,
>
>If you haven't checked out issue CB-3393[1], you should. I believe this is
>a pretty big problem and brings i
Hey All,
If you haven't checked out issue CB-3393[1], you should. I believe this is
a pretty big problem and brings into question the way we are loading
plugins.
Using an absolute path is not going to work as Braden suggests in the
comments of the issue. He proposes adding code to cordova.js that
Hey Bryan,
Thanks for chiming in. I realized this after I made the change yesterday.
Tracking it with https://issues.apache.org/jira/browse/CB-3393
Cheers,
-Steve
On May 15, 2013 5:34 AM, "Bryan Higgins" wrote:
> Thanks Steve. I meant to bring that commit up on the list.
>
> The problem is that
Thanks Steve. I meant to bring that commit up on the list.
The problem is that the relative reference to cordova_plugins.json only
works when the page is in the same directory as that file. Is that also an
issue on ios/android? If so, is there a standard cross platform way to
reference a file in t
Hey All,
The BB10 stuff got merged into cordova.js. The following commit breaks
plugin_loader for ios + android.
https://github.com/apache/cordova-js/commit/8d59461c6f796f2c88a0eae2467cc663897ccce9.
I am going to remove the slash for now.
-Steve
12 matches
Mail list logo
