On 2012-07-09 17:04 , David Karger wrote: > It's not "my" unstable hack; it's a trick that I'd seen in various other > open source projects and assumed was widespread.
Yes, it is. Anonymous functions are not the sole piece I was finding serious fault in. It was in combination with blindly modifying source. > I agree that both solutions require taking steps to make the right > jQuery available to Exhibit. > > My point (stated in contrapositive) was that once you do something to > make the right jQuery available, you might as well bind it to $ since > that's the only $ we care about using in Exhibit. Fair enough, as far as anonymous functions go. But the scheme you wanted to accomplish this with taken as a whole is just not that simple. It's integral to its supposed simplicity that you just add a step to distribution building, except that doing only that ignores the questions that should come with such a change. When you add in version mitigation, the behavior of pre-distribution code no longer even matches that of post-distribution code. > However, it is not "important" to me that it be done that way. I > pointed out the option and its rationale, but you can do what you like. Great. > On 7/9/2012 7:51 PM, Ryan Lee wrote: >> On 2012-07-09 16:01 , David Karger wrote: >>> My objection to using just "jQuery" is that it doesn't really fix the >>> problem. What if someone loads a (far past or far future) version of >>> jQuery that breaks Exhibit? If you truly want to isolate Exhibit's use >>> of jQuery from all else, you need to use Exhibit2's "SimileAjax.jQuery" >>> namespacing. And have Exhibit load its own version without overwriting >>> any previously loaded version. And then return $ and jQuery to their >>> prior bindings after the loads. >>> >>> Which is a lot more complicated than just saying jQuery instead of $. I >>> was suggesting something that seemed simpler to me. >> I am quite a bit less concerned about jQuery versioning problems. This >> may be something we can deal with more easily if we move to RequireJS; >> also, in a great wide ocean of code, I'm not convinced we can avoid all >> conflicts while reusing others' great code - the line has to be drawn >> somewhere. Perhaps jQuery is worthy of that attention because of its >> widespread deployment. >> >> At any rate, I may be missing something, but I still don't see how >> incorporating versioning mitigation with a global replace is less simple >> than everything I outlined as a flaw in your unstable hack below. In >> fact, I'm not sure you've answered my question. Don't both solutions >> require taking steps to make the right jQuery available without >> corrupting other jQuery versions potentially in use? Your hack is about >> retaining the use of $, and as far as I can tell doesn't directly deal >> with versioning. Given that both solutions need the same mitigation >> process in place, what exactly is the advantage of doing it your way, >> and why is it important to you that it be done that way? >> >>> On 7/9/2012 6:35 PM, Ryan Lee wrote: >>>> On 2012-07-07 21:51 , David Karger wrote: >>>>> On 7/7/2012 2:04 AM, Ryan Lee wrote: >>>>>> On 2012-07-06 09:52 , David Karger wrote: >>>>>>> On 7/6/2012 3:42 AM, Ryan Lee wrote: >>>>>>>> Hi Jed, >>>>>>>> >>>>>>>> On 2012-05-31 09:44 , jedavis13 wrote: >>>>>>>>> Hello, I am porting Exhibit 3 to an existing Drupal app and have >>>>>>>>> some >>>>>>>>> questions as to the choice of using '$' instead of jQuery in the >>>>>>>>> bundled scripts. In order to get exhibit to work I had to manually >>>>>>>>> edit each script and replace $ with jQuery. There must be another >>>>>>>>> way >>>>>>>>> around this yes? I tried writing a jQuery no-conflict script, but >>>>>>>>> that >>>>>>>>> was not working. >>>>>>>>> >>>>>>>>> Any suggestions would be greatly appreciated. Currently it's >>>>>>>>> working, >>>>>>>>> however I am not happy with having to modify the core. Here is a >>>>>>>>> link >>>>>>>>> to the page if this helps, >>>>>>>>> http://kang.ccnmtl.columbia.edu/sb/jed/drupal7_lowernysphtc/dgcore/col-matrix >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> I'm afraid this is access-restricted >>>>>>>> Thanks for pointing this out. Exhibit has (in my usage) generally >>>>>>>> been >>>>>>>> the only thing going on in a page, and any other code would be >>>>>>>> concerned >>>>>>>> with modifying its behavior. Clearly that isn't the best >>>>>>>> assumption to >>>>>>>> be making. >>>>>>> Since we're working on at least 3 tools that combine exhibit with >>>>>>> something else, I agree. So far it hasn't been a problem >>>>>>> because all >>>>>>> the tools we've used have made the same assumption that $=jQuery. >>>>>>> Jed, which particular tool have are you using that does not make >>>>>>> this >>>>>>> assumption? >>>>>> jQuery is not unique in deploying that shorthand, for instance $ >>>>>> could = >>>>>> Prototype. >>>>>> >>>>>>>> I used $ because it made typing easier and lines shorter (nothing >>>>>>>> deep >>>>>>>> there). I'm familiar with the use of closures to $ within a >>>>>>>> restricted >>>>>>>> scope, as most jQuery plugins do, but with our code base spread out >>>>>>>> over >>>>>>>> a lot of files, I am loathe to go down that road. I suppose we >>>>>>>> could >>>>>>>> just make the switch to use "jQuery" instead, though if you know >>>>>>>> of any >>>>>>>> other way we can have our cake and eat it too - the simplicity of $ >>>>>>>> without causing conflicts - I'd be interested to hear it. I'll see >>>>>>>> what >>>>>>>> else I can find on the topic. >>>>>>>> >>>>>>>> If nothing else, we could make sure the compressed version of >>>>>>>> Exhibit >>>>>>>> substitutes all $ usage for jQuery. >>>>>>> Since we have already separate the creation of a "distribution" of >>>>>>> exhibit from the underlying codebase, we could in theory do the >>>>>>> same for >>>>>>> the uncompressed version of exhibit, for example using using the >>>>>>> closure >>>>>>> of $ you mention by programmatically wrapping every js file in >>>>>>> function($) { >>>>>>> the file >>>>>>> }(Exhibit.jQuery); >>>>>>> as we copy it to dist. >>>>>> On further consideration, I'm not a great fan of using the closure >>>>>> method. This makes debugging tricky; similar to how I wouldn't >>>>>> want to >>>>>> debug the compressed code bundle, I don't think I'd want the extra >>>>>> effort involved in debugging source subtly modified from the >>>>>> original. >>>>> I don't think the two points are comparable; debugging the compressed >>>>> code is a clear nightmare of meaningless names; wrapping our code in a >>>>> closure that define $ would have no impact on any definitions in our >>>>> code (or on the code we see) while we debug exhibit; it would just >>>>> protect our code from having its definitions changed when combined >>>>> with >>>>> other code. >>>> Can you explain why it's at all important to you to preserve a >>>> developer >>>> shorthand? I'm hearing a straw man made out of my comparison (which >>>> made no mention of degree of similarity), and that without even >>>> explaining why it's so important to you to preserve the current status >>>> quo or what's so odious to you about doing the simple thing and just >>>> using jQuery. >>>> >>>> What you proposed is an unstable hack. Do you test the pre- or post- >>>> wrapped code? Which line is the bug on - should I subtract two from >>>> each report or ask each reporter to subtract two? It's not a huge >>>> deal, >>>> to be sure, but that's what additional overhead you propose calls into >>>> existence. More importantly, does Exhibit work perfectly with >>>> file-limited scopes? It might not. Should every file get wrapped? It >>>> might not even need it. Will it work as expected when everything is >>>> concatenated and compressed? Either someone does the footwork to >>>> verify >>>> it all works out (and they might as well go ahead and modify every file >>>> instead of converting it every time) or I can do the extremely simple >>>> and very easy change from $ to jQuery. >>>> >>>> You can try to convince me this is at all important or worth discussing >>>> further, but by then I'll already have a changeset lined up to make the >>>> switch - because in far less time than this topic has inflated to >>>> inexplicably occupy, I'll have implemented the simple solution that Jed >>>> already kindly offered. >>>> >>>>> It also seems like utterly standard behavior in many other libraries, >>>>> e.g. the Aloha editor I'm working with at present. >>>>>> There's some collected wisdom here: >>>>>> >>>>>> http://docs.jquery.com/Using_jQuery_with_Other_Libraries >>>>>> >>>>>> I'll want to check (or somebody else can check), but as Jed >>>>>> mentioned, I >>>>>> don't think having an ordered, late call to jQuery.noConflict() is an >>>>>> option. The most unambiguous solution is to do a global replace at a >>>>>> low level of $ with, say, a global e$ and set e$ = jQuery at the >>>>>> earliest point it comes into use, then broadcast the new >>>>>> convention to >>>>>> our developers. I do think we shouldn't be the ones calling >>>>>> noConflict; >>>>>> whether a user-developer wants $ for jQuery or something else >>>>>> should be >>>>>> their call, and Exhibit should avoid doing surprising things to the >>>>>> global context. >>>>>> >>>>>> Or we can just use jQuery. It's not that hard to type. >>>>>> >>> >> > > -- You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en.
