No, Rico.Toggler does not belong to Rico, and I (basing it on the Rico library) made the mistake of not declaring a new namespace for it so far.
(actually I was also considering donating it back to Rico at some point in time, let's see how this works out). I will correct this ASAP. regards, Martin On 10/8/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > > > 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. > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
