Ah, ok.
On Feb 13, 10:13 am, Aaron Newton <[email protected]> wrote: > Form.request doesn't inherit from request. It has a reference to an > instance of request HTML in it. > > -Aaron > > Sorry for any typos. Big fingers , tiny buttons. > > On Feb 13, 2010, at 10:05 AM, hairbo <[email protected]> wrote: > > > Actually, I have a question that's going to reveal how naive I am > > about object inheretence. If form.request is built on top of > > request.HTML, then why don't the request.HTML options just appear as > > top-level options of form.request? Why do they appear as "nested" > > options? > > > On Feb 12, 3:42 pm, hairbo <[email protected]> wrote: > >> Boom. Thanks. > > >> On Feb 12, 2:59 pm, Aaron Newton <[email protected]> wrote: > > >>> The docs say that spinnerTarget is part of the default options > >>> passed to the > >>> Request instance: > > >>> * requestOptions - (*object*) The options passed on to the > >>> instance of > >>> [Request.HTML] created by the class that sends the form. Defaults to > >>> *{evalScripts: true, useSpinner: true, url: <the form url>, > >>> emulation: > >>> false, spinnerTarget: <the update argument>}*. > > >>> What this means is your code should look like this: > > >>> new Form.Request( > >>> id, > >>> container, > >>> {requestOptions: { spinnerTarget: > >>> container } } > >>> ); > > >>> Spinner integrates with Request; so it's the Request's options you > >>> need to > >>> specify here. You'll note in the relevant code that it calls > >>> $merge on the > >>> fault options and this.options.requestOptions. > > >>> On Fri, Feb 12, 2010 at 12:06 PM, hairbo <[email protected]> wrote: > >>>> Hi, > > >>>> I'm using Form.Request, and just discovered that it can do that > >>>> nifty > >>>> spinner thing. It wasn't working for me initially because I didn't > >>>> have the proper spinner styles or the graphic. So I grabbed those, > >>>> and it's basically working, but now I'm having a problem with > >>>> spinnerTarget. > > >>>> According to the docs, I should be able to pass in an element or > >>>> id of > >>>> an element to "spinnerTarget", and during the submit, that given > >>>> element should be where the spinner is applied. In practice, that > >>>> doesn't seem to be the case. My call looks like this: > > >>>> sessionsubmit: function (id, container) { > >>>> if($(id)) { > >>>> var gsubmit = new Form.Request( > >>>> id, > >>>> container, > >>>> {spinnerTarget: container} > >>>> ) > >>>> } > >>>> } > > >>>> If I do console.log() on "container" or even $(container), the code > >>>> finds it, so I know it's there. However, it would appear that the > >>>> underlying Mootools code is hardwired to have the spinner appear on > >>>> the form (in my case 'id'). Here's what I think is the relevant > >>>> code: > > >>>> makeRequest: function(){ > >>>> this.request = new Request.HTML($merge({ > >>>> url: this.element.get > >>>> ('action'), > >>>> update: this.update, > >>>> emulation: false, > >>>> spinnerTarget: this.element, > >>>> method: this.element.get > >>>> ('method') > >>>> || 'post' > >>>> }, this.options.requestOptions)).addEvents({ > >>>> success: function(text, xml){ > >>>> ['success', > >>>> 'complete'].each(function(evt){ > >>>> this.fireEvent(evt, > >>>> [this.update, text, xml]); > >>>> }, this); > >>>> }.bind(this), > >>>> failure: function(xhr){ > >>>> this.fireEvent('failure', > >>>> xhr); > >>>> }.bind(this), > >>>> exception: function(){ > >>>> this.fireEvent('failure', > >>>> xhr); > >>>> }.bind(this) > >>>> }); > >>>> }, > > >>>> It would appear that "spinnerTarget" is hardwired to the ID of the > >>>> form being submitted. Maybe I'm missing something... > > >>>> Thanks for any guidance.
