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