I've tried this same process with jquery 1.3.2 and jquery ui 1.7.2. same problem.
(jquery 1.3.2 alone mucks up with firefox toolbar additions--not just my extension but also Extension Developer's chrome reload icon and Firebug's inspect icon. might be a naming conflict or something) I've been mucking with this further. I've been looking for funny this/ jquery references inside the ui code....maybe something non-re- entrant. I wouldn't be surprised if the fault is in my code...it's just, I think I know how my code works ?? Lucy. On Nov 30, 12:19 pm, lucy <[email protected]> wrote: > Hi, > > I'm calling jquery.ui version 1.6 from a Firefox extension. I'm > getting an interesting problem. > > Whenever some ui widget calls $("<<some html>>"), this.element is > over- > written by the element just created. > > UI plugins that don't do this kind of thing, eg the effects, work > fine. The slider plugin, which I am particularly interested in, does > this when creating the handle. Even if I create the handle before > calling slider, other parts get messed up. > > If this is the wrong list, let me know. I wasn't sure where to go for > help. I've spent much of today debugging this, and I thought you might > have more insight on working with jquery.ui. I appreciate any help you > can provide. > > I've included relevant code below. My guess is that the problem is > some kind of scope/closure issue...or maybe I'm not loading jQuery or > jQuery.ui correctly. My extension receives page load events, and from > that loads jQuery with the appropriate context. It then loads > jQuery.ui. > > I'm running Firefox 3.5 on Mac OS 10.5.7. > > If you have questions let me know. I'm still learning good Javascript > practices. > > Thanks, > Lucy. > > jquery ui all 1.6: > > /** > * Add the jQuery_UI function to encapsulate entire UI in a function > * so that we can pass in the > * jQuery+context created by the request instance. > */ > function jQuery_UI(jQuery) { > > (function($) { > > var _remove = $.fn.remove, > isFF2 = $.browser.mozilla && (parseFloat($.browser.version) < > 1.9); > > <<elided>> > > $.widget("ui.slider", { > > _init: function() { > > var self = this; > this.element.addClass("ui-slider"); > this._initBoundaries(); > > // Initialize mouse and key events for interaction > this.handle = $(this.options.handle, this.element); > if (!this.handle.length) { > self.handle = self.generated = $ > (self.options.handles || [0]).map > (function() { > var handle = $("<div/>").addClass("ui- > slider-handle").appendTo > (self.element); > // Mark A: at this point, self.element > becomes the ui-slider- > handle element! > if (this.id) > handle.attr("id", this.id); > return handle[0]; > }); > } > > note that the occurrence at Mark A is not limited to this situation. > for example, simplifying the above with the following still results in > self.element being over written at Mark A by the test element (or > rather, this.element.attr("class") then equals "test"): > > var self = this; > this.element.addClass("ui-slider"); > this._initBoundaries(); > var x = $("<div class=\"test\"></div>"); > // Mark A > > cloning self.element and then resetting it after Mark A does > work...but that only solves this particular problem right here. > > The extension's "views", in this case slider_test_page, access jquery > in the following manner: > > slider_test_page: function(request) { > << neat django template-style rendering elided--this is cool > because we share templates with our server. this isn't relevant, but > it is interesting. if you want to know more send me an email. i wish i > could provide something more jquery ui-ish in return, but that's all i > got. >> > > var jq = request.add_jQuery_ui(); > jq("#slider").slider(); > > } > > Finally, here is the code for loading jQuery into the request: > > function PageRequest(url, event) { > this.url = url; > this.event = event;} > > PageRequest.prototype = {}; > _extend(PageRequest.prototype, { > add_jQuery_ui: function() { > var self = this; > // the jQuery referenced inside here refers to the > object loaded by > the jQuery library > var jq = function(selector, context) { > return jQuery.fn.init(selector, context || > self.get_document()); > }; > jQuery.extend(jq, jQuery); > jQuery_UI(jq); > return jq > }, > get_document: function() { > var document = this.event.originalTarget; > return document; > }, > <<elided>> > > A couple extra things. These probably aren't relevant, I'm just trying > to get my thoughts straight: > > 1. Views normally access jQuery via a different request method: > jQuery: (function() { > // the jQuery referenced inside here refers to the > object loaded by > the jQuery library > var jq = function(selector, context) { > //logger("request.jQuery(): " + selector + > this.event); > return jQuery.fn.init(selector, context || > this.get_document()); > }; > jQuery.extend(jq, jQuery); > return jq; > })(), > > Whenever I loaded ui from that method, the closures would get fun. I > can't remember exactly what caused what, but I struggled with > this.get_document being undefined, and the jQuery getting passed to > jQuery_UI being just the jQuery prototype...no fn property, etc. > > 2. When I hack the sliders to work, eg correcting for the over writing > by cloning the original element and resetting it later, the handle > appears, but doesn't respond to mouse events or anything....so i guess > by work I mean that no exceptions occur. Still, when that occurs, then > reloading the page causes infinite recursion. I've tried only loading > jQuery_UI when jq("<div />").slider() raises an exception. No effect. > > 3. I have to use jquery 1.2.6 because of a Firefox extension bug...or > something. Maybe it's worth testing the latest versions of both in > case that clears things up. -- You received this message because you are subscribed to the Google Groups "jQuery UI" 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/jquery-ui?hl=en.
