Thanks for your replies. @Thomas, I see now how they are of course raw DOM elements. I will try compile and run in a browser and measure the performance, it ought to be a lot quicker.
I took a brief look at GWTQuery, it looks good, but seems to be an implementation of the entire jQuery library? All I am after is a native javascript selector library, the effect would sort of be like taking the Sizzle library, loading it into the app and then having a JSNI method talk to it. Sure that would be more direct than importing the entire GWTQuery library (in my limited case anyway). Thanks for the tips. On Jun 24, 1:32 pm, Thomas Broyer <[email protected]> wrote: > On 24 juin, 11:46, Paul Schwarz <[email protected]> wrote: > > > > > > > In Mootools et al. it is really easy to select all elements in the DOM > > with a given attribute, such as CSS class. In Mootools this is > > var listOfDivsWithClassRED = $$(".RED") > > > I have a need to select all the elements on a page with a given > > attribute and value and I'm trying to mimic Mootools functionality AND > > speed! > > > I > > found:http://stackoverflow.com/questions/2406002/find-an-element-by-css-sel... > > and then saw Robert > > Hanson's:http://gwt-widget.sourceforge.net/docs/xref/org/gwtwidgets/client/uti... > > > Robert Hanson's recursion idea seems correct to me, except in my case > > the execution time is 5500ms for a typical page. Due to the structure > > of my markup I know that the elements I am interested in will not > > occur deeper than a certain depth on the DOM tree, so I put a > > recursionMaxDepth concept into my recursion and now I'm down to > > 3000ms. > > > That's still too long, but I know how to solve it. The problem is (see > > Robert's code) we are dealing with GWT Elements. For example, see the > > lines: > > c = DOM.getAttribute(element, "className"); > > Element child = DOM.getChild(element, i); > > > So in my case the recursive function is inspecting about 1000 elements > > on the page (which is fine) but then GWT is turning each child element > > into an Element just to inspect an attribute and value pair, and then > > it discards the Element if it doesn't match my criteria. That's VERY > > expensive. > > > I need a way to spin through those 1000ish elements quickly, treating > > them as "raw DOM elements", maybe Nodes, and then do the attribute > > matching on those light-weight objects. If one of them matches then > > GWT can turn it into a full blown Element object. > > They *are* "raw DOM elements"... when compiled! > (Element inherits JavaScriptObject) > > Of course in DevMode, you're then switching many times between Java > (in DevMode) and JavaScript (in the browser), with TCP communication > in between! > The "workaround" would be implement everything in a single JSNI > method, but then you'd have to duplicate your method with tweaks for > each supported user.agent, or lose the advantage of deferred-binding > for com.google.gwt.dom.client.* (compiling only the browser-specific > code). > > I'd however use GwtQuery, as suggested instead of trying to re- > implement it. AFAICT, it even uses querySelectorAll in browsers that > supports it (i.e. recent versions of all of them, including IE8). -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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/google-web-toolkit?hl=en.
