Martin Cooper wrote: > Can I suggest a high-level discussion of how you're going to structure > all of the JavaScript code in MyFaces? I'm concerned that you'll end up > with a fragmented JavaScript code base, with each widget using its own > style and way of doing things, which would be, um, less than optimal. > > I'm also very concerned right now that, unless I'm mistaken, all of the > code seems to be going into the global JavaScript namespace. This is OK, > I guess, if you're building an application, but it's definitely not OK > for a toolkit, since you're quickly going to end up with conflicts as > people use your toolkit to build applications. (Unfortunately, it seems > that the Prototype toolkit itself has this problem.) > > My 2 cents... > Very good idea, I am interested in that too, because the more we move towards ajax the more javascript dependencies we get... Also we need some consensous which javascript libs for now we use.
Currently Martin and I settled for the proto lib (he for the accordeon panel and the ajax stuff, I for the effects tag) in the sandbox depending on it, DWR is out of the scope for both of us afair because it introduces yet another set of xml config files. (Cannot speak for Martin directly, of course, but I remember such a discussion I had with him) Martin in the sandbox already has moved the proto lib stuff into its own and slowly is introducing stuff which is based upon it (the accordeon panel for instance), we should follow something like that approach. proto loader ... scriptaculo.us separate loader but having a dep into proto and shared over components ... other libraries also shared ... local component stuff still local but it should be recommended to dock to one of the existing libs to keep the code as tight as possible (prototype based code has the tendency to be very tight due to the oo structures prototype introduces to javascript) As for the introduction of DWR... I would stay away from it until they have resolved the xml config file issues There isnt too much in DWR which cannot be solved in proto or one of the libs. To my knowledge most of the interesting stuff on the javascript side itself currently is driven by Rails and proto based stuff, so it would be wise to follow that approach for the time being.
