Element.childrenWithClassName() in script.aculo.us was always meant as an internal method, dating back from the dark ages of script.aculo.us-- the internal usage is now replaced by using the much more powerful Selector API.
Sorry for the confusion, the corresponding CHANGELOG entry is: * Do some refactoring to make use of Prototype 1.5 functionalities and save LOC (see http://dev.rubyonrails.org/changeset/5174) btw, please, please try using script.aculo.us edge (that is, latest SVN). edge is nearly always perfectly stable, and this way we can find bugs like this much easier (for example, this particular change was on September 24!). :) -Thomas Am 14.11.2006 um 09:22 schrieb Sébastien Gruhier: > > Thanks a lot Pete, I have updated Prototype Carousel widget, (http:// > prototype-carousel.xilinus.com/). > In fact, Element.childrenWithClassName was in effect.js but I found > nothing about it in the 1.6.5 change log (http://dev.rubyonrails.org/ > browser/spinoffs/scriptaculous/CHANGELOG?rev=5468) > which is not very cool. > > Now I have to check my other projects :( > Seb > > > On Nov 14, 2006, at 8:55 AM, Christophe Porteneuve wrote: > >> >> Pete Forde a écrit : >>> However, the code in question was Sebastien Gruhier's Prototype >>> Carousel widget, (http://prototype-carousel.xilinus.com/) which is >>> well designed, fairly recent, and perhaps unfortunately, widely >>> used. >>> I say unfortunately only because the moment people upgrade their >>> scripts - or soon, Rails 1.2 - they are in for a nasty surprise. >> >> At any rate, I'll notify Sébastien about this, so he gets a chance to >> fix it ASAP. >> >>> ps. From the looks of the latest RC, it's apparently time we all >>> start mastering XPath. >> >> XPath is a useful tool to have at your belt anyhow. With browsers >> increasingly implementing DOM 3 XPath (OK, true enough, you'll >> have to >> wait for another loooong while before IE burps it out), this makes >> for >> efficient-yet-fine-grained element selection. >> >> However, I don't see a very near future where Prototype would rely >> extensively on it w/o alternatives. And the full XPath syntax is too >> large to be usefully implemented from within Prototype (well, there >> are >> existing implementations out there, like GoogleAJAXSLT's xpath.js, >> but >> most of them are slightly incomplete anyhow). >> >> This syntax is also kinda inconsistent in some places (just look at >> the >> syntactic similitude between axes and functions, which is >> confusing at >> first). >> >> So don't fidget too much on XPath if your sole source of apparent >> need >> for it is Prototype. Of course, if you're harvesting large XML >> datasets >> as a daily matter, that's another matter entirely :-) >> >> -- >> Christophe Porteneuve a.k.a. TDD >> "[They] did not know it was impossible, so they did it." --Mark Twain >> Email: [EMAIL PROTECTED] >> >>> > > > > -- Thomas Fuchs wollzelle http://www.wollzelle.com questentier on AIM madrobby on irc.freenode.net http://www.fluxiom.com :: online digital asset management http://script.aculo.us :: Web 2.0 JavaScript http://mir.aculo.us :: Where no web developer has gone before --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
