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:
http://wrath.rubyonrails.org/pipermail/rails-spinoffs/2005-September/000827.html
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:
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.
