Oh I'm such a tool! There I was trying to shave 5500ms down to 3000ms
and down even further... I compiled into javascript and tested in
Chrome and my execution times hover anywhere between 0ms and 2ms!!!
High 5's all around!
But getting back to GWTQuery, it looks interesting, but now that I've
solved my "Element selector woes" why else should I delve into
GWTQuery? I am using the layout panel's animation effect similar to
the Expenses example, would GWTQuery replace that animation with a
"better" library? I just can't visualise it right now but if I think
of the power of GWT combined with jQuery style effects and things that
would be pretty amazing.
On Jun 24, 1:58 pm, Paul Schwarz <paulsschw...@gmail.com> wrote:
> 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 <cl_for_mail...@gmx.net> 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 <paulsschw...@gmail.com> 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 <t.bro...@gmail.com> wrote:
>
> > > > On 24 juin, 11:46, Paul Schwarz <paulsschw...@gmail.com> 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 google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
