I don't know why you're using class variables here. that's just wrong to begin with. it looks like this basically bypasses relocating in most circumstances. this makes assert_exists do pretty much nothing. that's fine in many circumstances, but it'll fail when things start modifying the dom with javascript. the ole object will become invalid, and should be relocated, but this bypasses that. watir should be doing two things, I've found: be better about only checking if an element needs relocating when operations have been performed which may have modified the dom; and check if the ole object is in fact still attached to the dom before trying to relocate.
On Fri, Aug 26, 2011 at 10:31, Michalski Jerzy <[email protected]>wrote: > > Following Zeljko's suggestion, I resume here the problem I presented in > "Watir is slow with nested frames" thread of the Watir General group (* > https://groups.google.com/forum/?pli=1#!topic/watir-general/nVVXggWAJJ4*<https://groups.google.com/forum/?pli=1#!topic/watir-general/nVVXggWAJJ4> > ). > > I use Ruby 1.8.7, Watir 1.9.2, IE8 > > Problem: > When I execute an action on an element placed in a deeply nested frame, the > method assert_exists from the Element class is called again and again by > many methods, also by those called by assert_exists! As a result, for my > simple example of 7 nested frames (see the thread "Watir is slow with > nested frames" for details), this method was called 1536 times! The same > elements were located again and again with exactly the same criteria (@how, > @what and @container)! > > My solution > I modified the method assert_exists by adding four class variables that > store the three location criteria and the OLE object found. Next time when > the method assert_exists is called, the new criteria are compared with the > previous ones. If they are the same, no need to 'locate' again, simply > return the object found previously. After my modification, the method > assert_exists is called only 17 times (always with my simple example), and > the real location is done only 8 times (7 frames and one text field) - other > 9 calls return the previously located objects. And everything takes less > than 1 second (compared to 15 seconds before!). > > Here is the modified method: > > def assert_exists > if respond_to?(:locate) > if (defined?(@@how) && defined?(@@what) && defined?(@@container) && > defined?(@@o) && > @@how == @how && @@what == @what && @@container == @container) > # The element has already been located -> take the already > located OLE object > @o = @@o > else > # Locate the element... > locate > # ...and save the information that served to locate it... > @@how = @how > @@what = @what > @@container = @container > # ...and also the located OLE object. > @@o = @o > end > end > unless ole_object > raise UnknownObjectException.new( > Watir::Exception.message_for_unable_to_locate(@how, @what)) > end > end > > Question: > As I am new to Watir (and Ruby), maybe I have ommited an important > functionnality that may be broken by my modification. Is there a downside > to this? > > Jurek > _Disclaimer > Vaudoise.ch______________________________________________________________-_ > Le présent courriel, y compris les pièces jointes, s’adresse exclusivement > à la (aux) personne(s) ou à la société à laquelle (auxquelles) il est > destiné et peut comporter des informations confidentielles et/ou protégées > par la loi. Toute divulgation, reproduction ou utilisation de ces > informations est interdite et peut être illégale. Si vous n’êtes pas > destinataire de ce courriel, merci de le détruire immédiatement et d’en > aviser l’expéditeur. > This e-mail, including attachments, is intended for the person(s) or > company named and may contain confidential and/or legally privileged > information. Unauthorized disclosure, copying or use of this information may > be unlawful and is prohibited. If you are not the intended recipient, please > delete this message and notify the sender. > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
