Seems reasonable.
On Dec 14, 2011, at 7:33 PM, Daniel Antonio Peraza Cedrez <
danielper...@gmail.com> wrote:
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.
>
>
>
>
