myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <we...@gmx.at>
Subject Re: JavaScript in MyFaces (was Re: New date parser in javascript)
Date Sat, 08 Oct 2005 16:35:54 GMT
Martin Cooper wrote:
> Let me give a couple of examples of problems MyFaces is facing right now.
> 
> 1) Prototype messes with fundamental JavaScript types. One of the first
> things is does is add a new function to Object! Things like this can
> seriously mess up other JavaScript code. As just one example, it renders
> the 'for ... in ...' construct effectively useless, because you will
> *always* get back more entries than you put in, since Prototype is
> adding some for you. And it's not only to Object, either, as even a

> quick glance at prototype.js will show.
> 
Issue is fixed soon, apparently the authors are aware of this problem:

http://wrath.rubyonrails.org/pipermail/rails-spinoffs/2005-September/000827.html

This is pretty much the only issue the basic proto lib has with conflicts
into other subsystems (except for maybe the namespace stuff), to my knowledge if
someone knows others please point me towards it.

> 2) Namespacing is a big problem already. Prototype, Rico and all the
> other JavaScript code I've looked at in the MyFaces repo create numerous
> artifacts in the global namespace, often with names that are very likely
> to be chosen by other people writing JavaScript (although Rico is much
> better in this respect). Examples: Prototype creates Form and Field,
> Rico and Scriptaculous create Effect. These will either clobber, or be
> clobbered by, other artifacts from other sources used in the same page.
> 
I agree with this problem, it can be easily fixed, either by us
or by others, fact is,
the code does a lot which we have to duplicate and there is definitely
a huge momentum behind that codebase, that things like OpenRico and Scriptaculous
exist is proof enough, so it would be sad to lock it out
especially for a problem as easily fixable as that one

> 3) The biggest problem area with the above is portlets. You have *no*
> control over what other JavaScript is going to be included on a page.
> This makes the likelihood very high that #1 and / or #2 is going to
> screw up all of the other portlets on the page, even if it doesn't screw
> up the portlet created by MyFaces. Either that, or the MyFaces portlet
> will be screwed up by the other JavaScript. Either way, that will not
> make you many friends. ;-)
> 
Actually I do not see portlets really as the problem, if we have a single
include of the lib and the namespace issue is fixed.
The library itself is fully OO which means you work with single objects
per portlet,

for instance portlet a uses a fade
portlet b uses a simple puff

portlet a:

onload="javascript:new Effect.Fade(this);"

portlet b:
onClick="javascript:new Effect.Puff(this);"

Two objects are generated with no conflicts at all between those portlets.

If an author however thinks he has to to some special stuff in his/her portlets
within the same namespaces... well javascript allows that but
but in the end you might end up in a mess.

My general opinion is, the proto stuff is pretty safe portletwise,
other javascripts (believe me the proto stuff is some of the best you can find,
I have seen much worse) are much less save than proto regarding portlets.
Mainly the most portlet problematic javascripts are those who do not use
javascript classes at all but go for a pure functional approach,
often this stuff does not the proper way to encapsule the data
to handle those issues but
are coded for only one object at a time, which works normally then
on a single page but breaks heavily on a portlet environment.

Once the namespace issue is fixed, this is also fixed to a at least
for me satisfying degree.

> 4) Another thing that could be a problem at some point is that I see at
> least some code that is creating MyFaces classes inside of Rico's
> namespace (e.g. Rico.Toggler). Since you don't control that namespace,
> you could easily be hosed when a new version of Rico comes along that
> defines something with the same name that you are using. Here I would
> suggest simply defining your own namespace (e.g. MyFaces).
>
Martin has to comment on that, since he has the supervision over the toggler,
I have not checked it out yet except for the demo.


> 
> 
> There's also a lot of interesting and very sophisticated stuff going on
> that doesn't use either Rails or Prototype, including live commercial
> sites.
> 
> I would recommend taking a look at Dojo. It has excellent "Ajax" support
> and an awesome event system. It is also fully namespaced. See:
> 
> http://dojotoolkit.org/
> http://dojotoolkit.org/docs/intro_to_dojo_io.html
> http://dojotoolkit.org/docs/dojo_event_system.html
> 
I will check it out, having more than a handful of tools in our hands is always good.

Thanks for pointing me towards it I have not been aware of it.


Mime
View raw message