We did infact do such a thing: a component which, based on a TextField
ID, "decorates" it with JS event listener and thus adds ajax
functionality to the textField - but this is really no magic, and it is
not pluggable - textfield knows nothing about it, it only a JS thing -
(We wrote it because I didn't like the tacos way of pulling extensivley
pages out of my pool for each request, so this one uses a custom service
which delegates requests to custom data-provider->serialize-as-xml)
Now we were too lazy to duplicate TextField, so the component recieves a
textField as a parameter, and just generates the JS to call prototype's
Object instanciation.
I have no idea why the tacos component don't use the same technique...
Cheers,
Ron
PS - I still don't beleieve the 30+ functions thing - I like keeping it
flat and simple, but maybe I will love it when I see it... who knows...
Leonardo Quijano Vincenzi wrote:
You're getting me wrong. You're talking about monolithic components, I'm
talking about component composition.
I don't know what's the *best* way of doing this, design-wise, so please
don't jump in conclusions. I'm talking about why Ajaxcompleter has the
Textfield functionality copied.
So, instead of having 2 TextFields, one with standard functionality, and
one with autocomplete, we'd have some "component parts", or whatever you
should call it, that we "compose" together and build a full featured
TextField with 30+ functions.
It's not that the base component has 30+ functions. Is the *composition*
of components that has it.
Aren't validators and translators pluggable ? Why don't do the same with
Ajax?? Tacos is already doing it, I'm just talking about making it
official.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
