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.
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.
