myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: JavaScript in MyFaces (was Re: New date parser in javascript)
Date Sun, 09 Oct 2005 11:51:50 GMT
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 <martinc@apache.org> 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

Mime
View raw message