On Fri, 7 Oct 2005, Werner Punz wrote:
Martin Cooper wrote:
Can I suggest a high-level discussion of how you're going to structure
all of the JavaScript code in MyFaces? I'm concerned that you'll end up
with a fragmented JavaScript code base, with each widget using its own
style and way of doing things, which would be, um, less than optimal.
I'm also very concerned right now that, unless I'm mistaken, all of the
code seems to be going into the global JavaScript namespace. This is OK,
I guess, if you're building an application, but it's definitely not OK
for a toolkit, since you're quickly going to end up with conflicts as
people use your toolkit to build applications. (Unfortunately, it seems
that the Prototype toolkit itself has this problem.)
My 2 cents...
Very good idea, I am interested in that too, because the more
we move towards ajax the more javascript dependencies we get...
Also we need some consensous which javascript libs for now we use.
Currently Martin and I settled for the proto lib (he for the accordeon
panel and the ajax stuff, I for the effects tag) in the sandbox depending
on it, DWR is out of the scope for both of us afair because it
introduces yet another set of xml config files.
(Cannot speak for Martin directly, of course, but I remember such a
discussion I had with him)
Martin in the sandbox already has moved the proto lib stuff into its own
and slowly is introducing stuff which is based upon it (the accordeon
panel for instance), we should follow something like that approach.
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.
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.
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. ;-)
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).
proto loader
... scriptaculo.us separate loader but having a dep into proto and
shared over components
... other libraries also shared
... local component stuff still local but it should be recommended to
dock to one of the existing libs to keep the code as tight as possible
(prototype based code has the tendency to be very tight due to the oo
structures prototype introduces to javascript)
As for the introduction of DWR... I would stay away from it until they
have resolved the xml config file issues
There isnt too much in DWR which cannot be solved in proto or one
of the libs.
To my knowledge most of the interesting stuff on the javascript side
itself currently is driven by Rails and proto based stuff, so it would
be wise to follow that approach for the time being.
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
--
Martin Cooper
