I admit I've never looked at prototype, but what about the option of fixing the namespace issues and contributing the fixes back to the prototype project?
On 1/3/06, Werner Punz <[EMAIL PROTECTED]> wrote: > The namespacing problem can be resolved with code gens which add > automatically the namespaces, > > the javascript type problem is indeed there > (although it seems to be not that critical, due to the inherent messy > nature of javascript itself, but I agree > it is critical enough for a general purpose lib on a second thought) > > That leaves us with several options > > a) Leave the prototype code in and sandbox the components permanently > until the problems are resolved > > b) add another component package which has this stuff in to make > a clear distinction, in this one other portlet problematic components > can be added as well. > > c) Kick it out and loose lots of development functionality in an area > which has lots of momentum > > Option c) does not seem a very good one to me, because, face it proto has > lots of development momentum and there are myriads of cases where the > proto lib is a viable choice while only a handful are really problematic. > > My suggestion would be to sandbox this stuff for the forseeable future > until it is clear in which direction proto develops itself. > And if no clear solutions to the problems are done by the proto devs > themselves could maybe open a small subproject which is clearly marked > as problematic in some environments. > > > Werner > > Martin Cooper wrote: > > The main problems with Prototype are: > > > > 1) It messes with fundamental built-in JavaScript types. Any time a > > JavaScript library does this, it causes potential for conflict with > > other JavaScript libraries. The most obvious problem with Object has > > indeed been fixed, but there are still several more, and even more being > > added in 1.4 than are already present in 1.3.1. This type of coding can > > cause other code in the same page to break either simply because > > additional functions have been added, thus breaking code that relies on > > the standard JavaScript objects, or because multiple libraries modify > > the same built-in types by adding or replacing functions with different > > code. > > > > 2) Lack of namespacing. Namespacing is crucial to co-existing with other > > JavaScript code. Without it, you are pretty much guaranteed to run into > > collisions at some point. Prototype defines classes such as Field and > > Form in the global namespace.. Those are such obvious names that it's > > not going to be long before someone hits collisions with those in a > > heterogeneous environment. > > > > Now, these problems may sound like no big deal when you're writing a > > regular web app. You can probably find ways to work around them - when > > you're in control of the page. > > > > But in a portlet environment, these are *really serious issues*. In a > > portlet environment, you are *not* in control of the page; you are only > > in control of your portlet(s). Suppose you've written a very cool > > portlet, using MyFaces, and it uses widgets that in turn use Prototype. > > You tested your portlet, and you believe it all works just fine. Now one > > of your paying customers adds it to their corporate portal, and it > > breaks everything else on the page. That happened because the code in > > Prototype created issues with JavaScript code being used in other > > portlets on the page. That is now *your* bug, because the portal was all > > working until your portlet was added. Your boss asks you why this > > happened, and your answer is what? That the other portlets weren't > > written properly? That the MyFaces widgets you were using weren't > > written properly? > > > > You mention that Prototype is used extensively in the Ruby on Rails > > world. Yes, that's true. But you need to recognise that not only are > > most people in that world using _only_ Prototype, and its derivatives, > > but *they are not writing portlets*. They are writing apps with pages > > over which they have complete control. In those circumstances, you are > > much less likely to run into problems. > > > > That's not the case for MyFaces components. You don't know what your > > users are going to be doing with them. You have no idea what else might > > end up on the same page. You can't control that, because they could be > > used to build portlets, and it's only the final portal user that > > ultimately constructs the page. > > > > So my question to you (collectively, not just Werner ;) is this: Don't > > you want to build the most robust JSF components that you can? Don't you > > want to do everything you can to minimise the risk that your users - or > > their users - will run into problems *because* they're using your > > components? Do you want to run the risk that people shun MyFaces because > > (some of) the components are buggy when used in a portal environment, or > > any other heterogeneous environment? > > > > -- > > Martin Cooper > > > > PS: A couple of other references: > > > > http://blog.metawrap.com/blog/CommentView,guid,42b961d5-b539-4d9a-b1e0-108e546ae3e6.aspx > > http://www.nabble.com/Re%3A-quick-on-datetime-p2148947.html > > http://www.nabble.com/Re%3A-quick-on-datetime-p2150570.html > > > > > > On 12/29/05, *Werner Punz* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > > wrote: > > > > Ok because someone raised this issue, I thought things over and came to > > the conclusion a second time, there is no real issue. > > > > First of all, I am not an expert with the newer portlet libraries, but I > > have had some extensive knowledge with Jetspeed 1 ( 1.4b3 exactly, which > > once I did a bigger portal with) > > > > I do not see a huge deal with using the library in a portlet > > environment. At least not bigger than with any other javascript. > > But please correct me if I am wrong with it. > > > > First of all. What happens in a portlet environment. Several backend > > code related objects are replaced with ones which are then shared over a > > central context. > > Portlets themselves have for instance their own contexts managing their > > own environments. > > (In jetspeed1 it was just the jetspeed context which every portlet had > > its own and then the global turbine context which itself was derived > > from the velocity context of the underlying turbine framework) > > > > The rest is adjusting the events or special events to portlets (like > > minimizing, maximizing etc...) > > > > On the frontend side, you basically render the subforms into a single > > page by some kind of layouting mechanism (which already means the form > > layout has to be adjusted somewhat to the changed environment) > > > > So how does proto could conflict. > > a) ID handling, I do not really see a big problem there, portlets have > > to behave at the frontend like every other html page, thus > > the ids with same components over different portlets, have to adjust, if > > not you get bigger problems in other areas than javascript! > > > > b) Conflicting Javascript code. Given the fact that myfaces to my > > knowledge already has code in place which prevents double imports of > > javascript, there is no conflict on code import level. > > > > The rest is abstracted by the class/object structure to a certain degree > > all which basically has to be done, is that the javascript code either > > is inlined as event triggers, or that generated objects have to be > > adjusted to the component ids (which is mandatory anyway, due to the > > fact that you can use two different components of the same type on the > > same page) > > > > So I assume proto is way less critical in this area than normal > > javascript code which could run into double declaration problems of > > functions way easier if programmed sloppily. > > > > The rest of the conflicts is inherent in both pure javascript and > > prototyped javascript. (namespace conflicts conflicts due to dyanmic > > structures of the language etc...) > > > > c) Prototyes changing of base classes, > > yes this is indeed a problem and a problem the devs are aware, one huge > > issue has been arisen in the past with the addition of additional > > Methods to Object which basically caused in interference with iterations > > over object. This issue has been reported and is being or has been (I do > > not know the status exactly) addressed. > > This seems so far being the most critical problem of the proto lib, > > given its high usage percentage (it is the core js lib of rails) and > > that it has been actively developed for a while now, others should have > > arrived by now, but have not and if have been addressed. > > (one issue was a browser memory leak, which martin reported and was > > addressed in a short period of time) > > > > > > I do not see the proto lib as critical problem in a portlet environment, > > but given that my knowledge of those environments is somewhat old, you > > might correct me. > > Moving a code from a normal to a portlet environment never is that easy > > you sometimes run into conflicts, but the proto lib seems not like a > > showstopper to me. Not bigger or less big than in a normal page > > environment and not bigger than any javascript code in a portlet based > > system. > > > > I just wanted to drop this food for thought and discussion in here, > > because somebody asked the question, and I think it is a serious > > concern, and that is basically what I can conclude with my knowledge I > > have about this stuff. > > (My personal opinions about portlets generally being put aside) > > > > > >
