Got ya! Just testing the speed of the compiled version of my
implementation now and then I'll move onto GWTQuery in a few minutes.

On Jun 24, 1:54 pm, Chris Lercher <[email protected]> wrote:
> Don't worry about adding the entire GWTQuery library - the GWT
> compiler takes care of outputting only the code parts it needs from
> that library. This often means, that your code size will only increase
> by a few hundred bytes.
>
> On Jun 24, 12:47 pm, Paul Schwarz <[email protected]> wrote:
>
>
>
> > 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.

Reply via email to