Le 06-08-24, =E0 16:28, Anjo Krank a =E9crit :
> Am 24.08.2006 um 22:12 schrieb Jean-Fran=E7ois Veillette:
>> This would avoid the ajax framework to be a wo-wrapper on top of a
>> single js library.
>> This would let the framework be open to new feature and libraries in =
>> structured way.
> Actually, this is the worst of all worlds. Firstly, the packaging=20
> doesn't help unless you also use packages in your wod which I totally=20=
It only help because you can have multiple implementation of=20
DoSomethingComponent, without being named DoSomethingWithYUI,=20
I agree that using full class name is not as convenient, but what are=20
the other options ?
I personally do not hate it, I have a college that use it all the time=20=
(yes even for normal components). It was unusual at first, but it is=20
an absolutely valid way to write .wod bindings.
> Then you need to support and test all these components, wrap your own=20=
> head around both libs, you'd spread resources over these and for what=20=
Well, if someone add a 'dojo' package, I won't feel personally involved=20=
in testing and I would assume that the person adding it is the one who=20=
is going to make tests and maintenance.
> So that *someone* at *some* time comes and says "eh, can't we use=20
> this in mochikit" which is the one thing you don't support?
Yes, if someone ask for a mochikit component, what should we say :
1- Wonder - Ajax framework do not accept component from libraries other=20=
than ~a.short.list.of.libs~. Build your own framework ... and btw it=20
would be nice if it where publicly available, someone else might need=20
2- Wonder - Ajax framework will accept your code, make it compliant for=20=
integration with wonder's rules.
3- yet another option ... restructure the current ajax framework and =20
move the generic ajax components stuff ( mainly AjaxUtils and a couple=20=
others ) in the erextension framework.
Rename the current Ajax framework with something more inline with the=20
library it's wrapping (prototype / scriptaculous / rico, etc), so that=20=
if other people want another wrapper of some incompatible library (yui,=20=
google, dojo, etc.) they can create a new framework wrapper around it.
In that third option, the generic stuff would go in erextension, and we=20=
would develop multiple wo-wrapper framework around base libraries=20
(prototype, yui, google, etc.). I think it would keep each framework=20
well focused. We would still need an ~AjaxKitchenSink~ framework where=20=
small/single components / ajax trick not directly related to any majors=20=
libraries would go.
> If it doesn't we use one thing only unless there is a total must have.
Sooner or later, that " must have " component will be needed.
Sooner or later, we have to get ready.