Thanks for your suggestions!. The only problem left is the following: if
element A chains to element B, and element B to element C, then when element A
changes, elements B and C should change too (B should be updated with the XHR
response, and C should clear its contents in order to be ready when B changes
again).
I'm thinking to fire the target element's change event upon completion of the
XHR request, what do you think?
El 14/12/2011, a las 17:35, Aaron Newton escribió:
> Much better!!!!
>
> One note: the design pattern for arguments passed to the api work best when
> the selectors are not from the document root but rather from the target
> element. Target elements can still express a global target by doing '!body
> div.foo', but it's less ambiguous and easier to author patterns that don't
> step on each other.
>
> -a
>
> On Tue, Dec 13, 2011 at 9:03 PM, Daniel Antonio Peraza Cedrez
> <danielper...@gmail.com> wrote:
> I took a moment to think better and I decided to switch the implementation to
> Aaron's Delegator:
>
> Delegator.register('change', 'ChainedSelect', function(event, element, api){
>
> var target = document.getElement(api.get('target'));
>
> var url = api.get('url');
> var method = (api.get('method')) ? (api.get('method')) : ('post');
>
> var key = element.getProperty('name');
> var value = element.getProperty('value');
>
>
> var data = new Hash;
>
> data.include(key, value);
>
> target.set('load', {
> method:method,
> data:data
> });
>
> target.load(url);
> });
>
>
> El 01/12/2011, a las 09:38, Olmo Maldonado escribió:
>
>> Thanks for the contribution Daniel here's a few comments:
>>
>> 1. This will leak in IE. Take a look at your chainTo function. Each time
>> you call it you create each of the functions that you're merging with
>> options.request. Since some of the functions reference the element, IE would
>> keep that reference and when you close the page it will not release the
>> reference. That's a memory leak.
>>
>> 2. You're also adding a new addEvent('change') each time chainTo is called.
>> Try this: chainTo().chainTo(); // and change the select. You should get two
>> Requests. Instead you should this.retrieve('chainTo:request'). If not set,
>> then lazy load it. If they're new options, then just pass the options in the
>> send method of the Request.
>>
>> 3. You're not taking advantage of OO practices. I'd make a another class
>> that either composes a Request.JSON or extends Request.JSON.
>>
>>
>>
>> On Wed, Nov 30, 2011 at 11:02 PM, Daniel Antonio Peraza Cedrez
>> <danielper...@gmail.com> wrote:
>> Hi, I was looking for a chained select boxes plugin into the forge, but I
>> wasn't able to find one, so I wrote a simple function to extend Element.
>> Here is the fiddle: http://jsfiddle.net/enTsg/
>>
>> Please give me some feedback on how can I improve it. At first sight, the
>> only problem I see it's some interface bloating. May be I could simplify it
>> a bit.
>>
>
>
