Actually having no namespaces was just one of the critque points.
(the smaller one in my opinion)
The other one to my knowledge was (I was one of the prototype defenders
btw...)
that prototype fiddles around with basic javascript objects.
The most famous example being the Object object which caused
some third party libs which foreached over derivations from it to fail.
The most famous example being the struts client side validation which
basically was disabled by this, to my knowledge.
I know this problem has been fixed. But one of the main critique points
by the main critique was, that there are still many of those extensions
which could cause potential breakage.
No this also could be fixable by moving the prototype extensions into a
different object space (like object being left untouched and moving
the extensions into a prototype_object )
The question just is, is the current scheme severe enough problemwise
that we have to move away (I am affected codewise as well, but only to a
small degree)
The more I think of it the more I come to the conclusion yes,
unfortunately. While proto is perfectly fine for webapps which are self
contained, all this stuff might be too problematic for a base library
which can be intermixed with other systems.
kindof bad, because I really like the lib, and especially what Thomas
did with script.aculo.us
Martin Marinschek wrote:
Hi *,
we are using prototype in Apache MyFaces as our javascript library of
choice. Recently, there has been much discussion on our mailing list
as to the usability of prototype in a dynamic environments where
several javascript libraries are used.
The critics of prototype argue that the prototype objects are not
namespaced - and that prototype extends basic javascript-objects with
method names that could easily be duplicated by another framework.
Is there a line of defense for prototype here that I can use? I really
don't want to move everything over to dojo or some other library...
regards,
Martin
_______________________________________________
Rails-spinoffs mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
