myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <>
Subject Re: JavaScript in MyFaces (was Re: New date parser in javascript)
Date Sat, 08 Oct 2005 17:06:33 GMT

On Sat, 8 Oct 2005, Werner Punz wrote:

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

Great! I'll take a look at that. Hopefully they've fixed all of the cases, 
and not just Object. ;-)

> 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

I didn't mean to imply that you shouldn't use useful JavaScript libs. Just 
that some of these issues need to be discussed and resolved. It would be 
good to encourage the authors of those other libs to think about it more 
as well, so that you don't have to solve their problems. ;-)

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

That's exactly my point. Portlets built with MyFaces are going to coexist 
on pages with portlets not built with MyFaces. If one of those portlets 
defines an Effect class, for example, something's going to break.

Obviously you can't fix everyone else's problems. ;-) However, if I use 
Dojo, for example, I know that all of the Dojo code exists in the 'dojo' 
namespace, and I can create all of my code in the 'martinc' namespace, 
thus truly minimising the risk of clobbering or being clobbered. That's 
what I'm encouraging you to think about.

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

Along with the already-fixed extension problem, I agree.

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

Actually, on looking more closely, it seems that Rico.Toggler is probably 
part of Rico, but for some reason ships in its own file.

Martin Cooper

>> 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:
> 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.

View raw message