Re: plugin loader breakage from blackberry 10 merge into cordova js
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 a comparison of performance between the two systems, just as extra info, for sure. While I understand it is more complicated, with plugins breaking out, I don't think it's an elegant solution to expect users to add at least 1 script tag to each of their html pages per plugin manually. If you take a look at plugin_loader.js from cordova-js, it is not a massive amount of code (~120 lines). About as simple as it gets in terms of a script loader. I don't agree with the this is hard argument against this functionality. 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 tags 3) tired of being the curmudgeon on the list, but why do we keep making things more and more complicated? @purplecabbage risingj.com On Wed, May 15, 2013 at 4:07 PM, Steven Gill stevengil...@gmail.com wrote: 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/vxmd3yrr5i5q27w3?q=plugman+plugin_load er%2Ejs On Wed, May 15, 2013 at 3:07 PM, Steven Gill stevengil...@gmail.com wrote: 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 15, 2013 at 12:36 PM, Bryan Higgins br...@bryanhiggins.net wrote: 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 based on the cordova-js script tag. The original plan was to inject directly into cordova-js, which would have imposed a similar constraint, but a decision was made to use a JSON file to avoid code generation issues. Keep in mind that the path is relative to the HTML file, not the script making the XHR. On Wed, May 15, 2013 at 3:12 PM, Filip Maj f...@adobe.com wrote: 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 stevengil...@gmail.com 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 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 will search for the cordova_plugins.json file and reference it correctly. This feels very hacky to me and will lead to more issues. I believe we need to reconsider how we are loading plugins. I am hoping more people decide to chime in on this discussion. [1] - https://issues.apache.org/jira/browse/CB-3393 On Wed, May 15, 2013 at 9:12 AM, Steven Gill stevengil...@gmail.com wrote: 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 bhigg...@blackberry.com wrote: 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 the root of a cordova app? We had to do something similar in plugman. This has not yet been merged in: https://github.com/blackberry/cordova-plugman/commit/7f8b704b6d4eb7419ca a56faee743f841bc987bd On Tue, May 14, 2013 at 8:03 PM, Steven Gill stevengil...@gmail.com wrote: 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/8d59461c6f796f2c88a0eae2467c c663897ccce9 . I am going to remove the
Re: plugin loader breakage from blackberry 10 merge into cordova js
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 an additional script that would load and do the right thing. No impact on end users, no need for them to add additional script tags, reduced complexity and no failing local XHRs. @purplecabbage risingj.com On Thu, May 16, 2013 at 4:35 PM, Filip Maj f...@adobe.com wrote: 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 a comparison of performance between the two systems, just as extra info, for sure. While I understand it is more complicated, with plugins breaking out, I don't think it's an elegant solution to expect users to add at least 1 script tag to each of their html pages per plugin manually. If you take a look at plugin_loader.js from cordova-js, it is not a massive amount of code (~120 lines). About as simple as it gets in terms of a script loader. I don't agree with the this is hard argument against this functionality. 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 tags 3) tired of being the curmudgeon on the list, but why do we keep making things more and more complicated? @purplecabbage risingj.com On Wed, May 15, 2013 at 4:07 PM, Steven Gill stevengil...@gmail.com wrote: 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/vxmd3yrr5i5q27w3?q=plugman+plugin_load er%2Ejs On Wed, May 15, 2013 at 3:07 PM, Steven Gill stevengil...@gmail.com wrote: 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 15, 2013 at 12:36 PM, Bryan Higgins br...@bryanhiggins.net wrote: 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 based on the cordova-js script tag. The original plan was to inject directly into cordova-js, which would have imposed a similar constraint, but a decision was made to use a JSON file to avoid code generation issues. Keep in mind that the path is relative to the HTML file, not the script making the XHR. On Wed, May 15, 2013 at 3:12 PM, Filip Maj f...@adobe.com wrote: 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 stevengil...@gmail.com 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 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 will search for the cordova_plugins.json file and reference it correctly. This feels very hacky to me and will lead to more issues. I believe we need to reconsider how we are loading plugins. I am hoping more people decide to chime in on this discussion. [1] - https://issues.apache.org/jira/browse/CB-3393 On Wed, May 15, 2013 at 9:12 AM, Steven Gill stevengil...@gmail.com wrote: 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 bhigg...@blackberry.com wrote: 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
Re: plugin loader breakage from blackberry 10 merge into cordova js
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 the root of a cordova app? We had to do something similar in plugman. This has not yet been merged in: https://github.com/blackberry/cordova-plugman/commit/7f8b704b6d4eb7419caa56faee743f841bc987bd On Tue, May 14, 2013 at 8:03 PM, Steven Gill stevengil...@gmail.com wrote: 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
Re: plugin loader breakage from blackberry 10 merge into cordova js
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 bhigg...@blackberry.com wrote: 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 the root of a cordova app? We had to do something similar in plugman. This has not yet been merged in: https://github.com/blackberry/cordova-plugman/commit/7f8b704b6d4eb7419caa56faee743f841bc987bd On Tue, May 14, 2013 at 8:03 PM, Steven Gill stevengil...@gmail.com wrote: 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
Re: plugin loader breakage from blackberry 10 merge into cordova js
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 will search for the cordova_plugins.json file and reference it correctly. This feels very hacky to me and will lead to more issues. I believe we need to reconsider how we are loading plugins. I am hoping more people decide to chime in on this discussion. [1] - https://issues.apache.org/jira/browse/CB-3393 On Wed, May 15, 2013 at 9:12 AM, Steven Gill stevengil...@gmail.com wrote: 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 bhigg...@blackberry.com wrote: 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 the root of a cordova app? We had to do something similar in plugman. This has not yet been merged in: https://github.com/blackberry/cordova-plugman/commit/7f8b704b6d4eb7419caa56faee743f841bc987bd On Tue, May 14, 2013 at 8:03 PM, Steven Gill stevengil...@gmail.com wrote: 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
Re: plugin loader breakage from blackberry 10 merge into cordova js
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 stevengil...@gmail.com 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 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 will search for the cordova_plugins.json file and reference it correctly. This feels very hacky to me and will lead to more issues. I believe we need to reconsider how we are loading plugins. I am hoping more people decide to chime in on this discussion. [1] - https://issues.apache.org/jira/browse/CB-3393 On Wed, May 15, 2013 at 9:12 AM, Steven Gill stevengil...@gmail.com wrote: 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 bhigg...@blackberry.com wrote: 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 the root of a cordova app? We had to do something similar in plugman. This has not yet been merged in: https://github.com/blackberry/cordova-plugman/commit/7f8b704b6d4eb7419ca a56faee743f841bc987bd On Tue, May 14, 2013 at 8:03 PM, Steven Gill stevengil...@gmail.com wrote: 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/8d59461c6f796f2c88a0eae2467c c663897ccce9 . I am going to remove the slash for now. -Steve
Re: plugin loader breakage from blackberry 10 merge into cordova js
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 based on the cordova-js script tag. The original plan was to inject directly into cordova-js, which would have imposed a similar constraint, but a decision was made to use a JSON file to avoid code generation issues. Keep in mind that the path is relative to the HTML file, not the script making the XHR. On Wed, May 15, 2013 at 3:12 PM, Filip Maj f...@adobe.com wrote: 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 stevengil...@gmail.com 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 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 will search for the cordova_plugins.json file and reference it correctly. This feels very hacky to me and will lead to more issues. I believe we need to reconsider how we are loading plugins. I am hoping more people decide to chime in on this discussion. [1] - https://issues.apache.org/jira/browse/CB-3393 On Wed, May 15, 2013 at 9:12 AM, Steven Gill stevengil...@gmail.com wrote: 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 bhigg...@blackberry.com wrote: 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 the root of a cordova app? We had to do something similar in plugman. This has not yet been merged in: https://github.com/blackberry/cordova-plugman/commit/7f8b704b6d4eb7419ca a56faee743f841bc987bd On Tue, May 14, 2013 at 8:03 PM, Steven Gill stevengil...@gmail.com wrote: 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/8d59461c6f796f2c88a0eae2467c c663897ccce9 . I am going to remove the slash for now. -Steve
Re: plugin loader breakage from blackberry 10 merge into cordova js
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/vxmd3yrr5i5q27w3?q=plugman+plugin_loader%2Ejs On Wed, May 15, 2013 at 3:07 PM, Steven Gill stevengil...@gmail.com wrote: 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 15, 2013 at 12:36 PM, Bryan Higgins br...@bryanhiggins.netwrote: 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 based on the cordova-js script tag. The original plan was to inject directly into cordova-js, which would have imposed a similar constraint, but a decision was made to use a JSON file to avoid code generation issues. Keep in mind that the path is relative to the HTML file, not the script making the XHR. On Wed, May 15, 2013 at 3:12 PM, Filip Maj f...@adobe.com wrote: 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 stevengil...@gmail.com 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 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 will search for the cordova_plugins.json file and reference it correctly. This feels very hacky to me and will lead to more issues. I believe we need to reconsider how we are loading plugins. I am hoping more people decide to chime in on this discussion. [1] - https://issues.apache.org/jira/browse/CB-3393 On Wed, May 15, 2013 at 9:12 AM, Steven Gill stevengil...@gmail.com wrote: 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 bhigg...@blackberry.com wrote: 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 the root of a cordova app? We had to do something similar in plugman. This has not yet been merged in: https://github.com/blackberry/cordova-plugman/commit/7f8b704b6d4eb7419ca a56faee743f841bc987bd On Tue, May 14, 2013 at 8:03 PM, Steven Gill stevengil...@gmail.com wrote: 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/8d59461c6f796f2c88a0eae2467c c663897ccce9 . I am going to remove the slash for now. -Steve
