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 c
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 whe
On Tue, Dec 13, 2011 at 11: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 ta
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 patt
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 me
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
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 som
