I've already answered to that problem in the original thread at http://groups.google.com/group/watir-general/browse_thread/thread/9d5557820580249e
I've also added some suggestions along the line of the same points as Ethan brought up. Jarmo On Sun, Aug 28, 2011 at 11:46 PM, Ethan <[email protected]> wrote: > 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 >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
