>
> Le samedi 27 août 2011 14:55:20 UTC+2, Jarmo Pertman a écrit :
Okay, i have looked into this issue now. I've set a breakpoint just
> before the #text_field invocation and didn't see as many invocations
> as you did (didn't count them, but it was something in the lines of ~5
> times). I don't understand where did you get that number 1536.
>
I got this number from the ruby profiler by adding requre 'profile' at the
beginning of test_frame.rb.
When I count the calls of assert_exists programmatically, by adding $x+=1 in
the body of assert_exists and puts $x at the end of the program, I get 512
(obviously the profiler counts three times too many).
But still this is much too many! You can also add puts #{@what} to the body
of assert_exists to see exactly for which elements this method is called and
recalled before the actual set is done.
>
> Anyway, i looked at the code and saw that everything that can be done
> is already done.
I am not so pessimistic.
> All caches are dangerous if not implemented properly
I agree
> and your patch breaks the point of assert_exists:
> 1) the element is located at the first place
> 2) the element is removed from the DOM, e.g. assert_exists should fail
> 3) your patch returns the previously located element, e.g. the
> assert_exists doesn't fail
>
> Also, this makes #exists? also return "true" although it should return
> "false".
>
Two responses:
1) For cases with no frames: Each time assert_exists is called for a
given element by the method set (or any other method that interacts with
this element), it is first called for each frame containig this element, so
surely the cache will change and the element will be relocated.
2) For cases with no frames: Each time when you interact with a different
element (ie., with different locators), the cache changes. So to reproduce
your scenario I should do something like that:
- set my_text_field to a value
- wait till my_text_field is removed from the DOM (without Watir interacting
with any other element, as interacting would change the cache)
- set again my_text_field to a value (or do something else to my_text_field)
I can hardly imagine a need for such a test scenario in real life.
> In conclusion, i'd still say that the application which uses 7 nested
> (!!!!) frames is really badly made and should be rewritten anyway. No
> offence.
No offence! I have already said it is not me who created the application!
> So, it is just one really bad corner-case where it's slower
> than usual, but unfortunately i don't see any good solution at this
> moment how to solve it for everyone.
"Just one really bad corner-case", and I am just in it!
> I guess you can use #value for
> that specific case, but i'm pretty sure you will also have slower
> invocations with other methods.
>
Yes, the problem concerns every interaction with elements placed within
nested frames.
>
> Also, one solution would be to open that frame directly in your
> browser instead of accessing it through all the other 6 frames.
> Something like this with this concrete example or just create some
> helper module, which could generate the correct url:
> my_frame=ie.frame(:name, '7.6').frame(:name, '6.5').frame(:name,
> '5.4').frame(:name, '4.3').frame(:name, '3.2').frame(:name,
> '2.1').frame(:name, '1.0')
> ie.goto ie.url.gsub(/\d+\.html$/, my_frame.src)
> ie.text_field(:name, 'edit_box').set('123456789')
>
This would mean cutting the application into pieces (a piece per frame). And
these pieces will most probably not behave as the whole application...
Jurek
--
Before posting, please read http://watir.com/support. In short: search before
you ask, be nice.
[email protected]
http://groups.google.com/group/watir-general
[email protected]
