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)
