Sorry hack, was not in a bad way, I meant in a "clever" and fast way. :-) I don't see any problems adding the check for the global and returning.
On Tue, Mar 17, 2015 at 12:30 PM, Jesse <purplecabb...@gmail.com> wrote: > The problem is the multiple document.addEventListener duck punch calls, > and mismatching callbackIds. > > Checking 'window.cordova' is not really a hack imho, that is where we > export to. > We can re-eval if we ever hear of it actually happening. > Also, a window.onerror handler reveals the issue immediately, I will > document this more, plus it will tell you where your extra colon or comma > is ... More evidence this should be user-space, documentation and 3rd party > tooling. > > > On Mar 17, 2015, at 7:01 AM, Carlos Santana <csantan...@gmail.com> > wrote: > > > > I agree with Joe this looks like a User space problem. > > But in this particular case, I would say that if cordova.js is ran a > second > > time cordova.js should be robust and no errors no side effects should > > happened. > > > > checking with window.cordova, that feels like a hack, I would I agree a > > good hack :-) > > > > I would say that for now adding the quick check is valid solution, but I > > would open another JIRA issue for future deep investigation on the root > > cause of running cordova.js: > > - Is the problem in cordova.js code that is core? > > - Is the problem in plugin js code that gets run by cordova.js core? > > - Is the problem in 3rd party plugin js code that gets run by cordova.js > > core? > > > > > > > > > > On Mon, Mar 16, 2015 at 3:13 PM, Horn, Julian C <julian.c.h...@intel.com > > > > wrote: > > > >> Well, I can see that this is kind of a philosophical disagreement. > >> > >> Today having two <script> tags for cordova.js is defined to be an error. > >> As such the current behavior of cordova.js is correct. But you could > just > >> as well have said that it's not an error. I think that's a better > choice. > >> > >> I've spent most of my career working on software development tools for > >> various languages. Generally we try to minimize uncheckable > constraints or > >> "gotchas" when we can. This makes things a little harder for a few > tools > >> vendors and a little easier for large numbers of developers. That's > >> usually an easy decision to make. > >> > >> When you create a new Cordova project in the Intel XDK, we provide a > >> template that includes a script tag for cordova.js. This means the only > >> way you can lack the tag is if you delete it (or import a project that > was > >> missing the tag). That's a great thing: it makes it much less likely > that > >> users will forget to include cordova.js and wind up wasting hours > looking > >> for an explanation. > >> > >> However, the opposite mistake does still happen. People don't read the > >> entire template (why should they?) and think they have to add the tag > >> themselves. That's how new users sometimes get into this situation. We > >> would like that not to be an error; it just makes things a little > smoother > >> and more forgiving, which is our goal. > >> > >> I will certainly submit a pull request. > >> > >> Julian > >> > >> -----Original Message----- > >> From: Joe Bowser [mailto:bows...@gmail.com] > >> Sent: Monday, March 16, 2015 1:36 PM > >> To: dev@cordova.apache.org > >> Subject: Re: Introduction for Julian Horn > >> > >> On Mon, Mar 16, 2015 at 6:40 AM Horn, Julian C <julian.c.h...@intel.com > > > >> wrote: > >> > >>> > >>> The fix certainly does not require a large chunk of time! Here's the > >>> entire fix; you put this up near the top of cordova.js, inside the > >>> outermost function invocation: > >>> > >>> if (window.cordova) { > >>> return; > >>> } > >> And nothing is stopping you from issuing a pull request. While Jesse > and > >> I think that we shouldn't get into the practice of fixing people's JS > >> errors, I'm sure that someone in this project might agree with you. I > just > >> don't think it's a bug, or even an improvement. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > -- > > Carlos Santana > > <csantan...@gmail.com> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > > -- Carlos Santana <csantan...@gmail.com>
