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) > >
