It's not "my" unstable hack; it's a trick that I'd seen in various other
open source projects and assumed was widespread.
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.
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.
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 simile-widgets@googlegroups.com.
To unsubscribe from this group, send email to
simile-widgets+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/simile-widgets?hl=en.
