myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject Re: Prototype library and portlets
Date Sat, 31 Dec 2005 02:41:33 GMT
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.4than 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 <werpu@gmx.at> 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)
>
>

Mime
View raw message