At 05:46 PM 8/17/2005, Paul Rogers wrote:
some other things that we should consider:
table#to_a currently returns the cells as text. I think ( I think it was
Bret that suggested it) this should return an array of TableCell objects
which menas we need Table#to_text_array ( or similar name). This may well
break peoples existing code, so Im in 2 minds about it. I think it needs
to be done, but I dont want to piss people off by having to make many changes
The way to do it is to create a file in watir/old_table.rb that reverts to
prior behavior.
If anyone needs the old way, they can just add a require and they get it.
I'll probably do that with the those old camelCase commands for 1.5. (I'll
simply stop requiring watir/camel_case.rb fror watir.rb).
You can also release the new code in a separate file and get comments on it
first, before making it part of the watir package. I've done this with the
new IE#remote_eval method. (Which by the way, i'm prolly going to rename to
forked_eval for now, while we still need it.)
a method to get the html className of any element - or did this already
get in?
class_name, ahem. Yes i did that. You wrote the code, but then attached it
to a method called 'style'.
in many apps, on an error condition, a textfield may have a different
color background to highlight a mandatory field or erroronous entry, we
could then confirm by doing
if ie.text_field(:index,1).class_name == 'ErrorClass'
# some message confirm we got the right thing
end
The next step is actually to allow ie.text_field(:class, 'ErrorClass') to
work. This would be awesome. Actually my plan is to let any attribute be
able to be used here. It's just a matter of writing less code -- seriously.
The exception objects should have more info, so I can do
begin
ie.text_field(:index,1).set('foo')
rescue ObjectDisabledException => e
puts "Object is readoly!!"
puts e.how # displays index - maybe a better name is needed
puts e.what # displays 1 - maybe a better name is needed
puts e.url # displays the url of the error
puts e.page_title #
puts e. anything else?
end
Maybe. I think the how and why will eventually evolve into a more complex
structure that will allow multiple hows and whys -- like WET.
What we need is Element#inspect to describe how the object was invoked. I
think. This is how WET redefines the to_s method. I think we need two
methods -- one that says how the object was specified (and that probably
also reports on container/ancestor objects) and the other that lists
attributes in detail.
Maybe we give these two different names, neither of which is to_s or
inspect and then these names can have a default binding to these methods,
but this can easily be changed by frameworks (like WET) that want to do
things different.
I am also thinking that what we really need is a hook for an exception
handler, so people can customize it get the behavior they want.
----- Original Message -----
From: Bret Pettichord <[EMAIL PROTECTED]>
Date: Wednesday, August 17, 2005 4:31 pm
Subject: [Wtr-general] next steps
> 1. finish purging all camelCase names in methods and local and
> instance
> variables.
> 2. finish renaming stuff that has the wrong name (like all the
> references
> to containers called 'ieController')
> 3. separate logic for locating objects (get_object) so it can be
> configured
> separately without having to what the WET people did (change
> overriding
> syntax).
> 4. rip out winclicker and autoit and use wet/winobjects instead
> 5. make it so that anything that be a container; refactor
> different methods
> currently used for this (frames & forms)
>
> and then
>
> 6. defer invokation of COM calls until necessary
>
> I've been pushing us this way for a while and believe that it is
> more
> important than ever. The simplest example of what this means is
> that code
> like this will work:
>
> table = ie.frame(:name, 'foo').table(:index, 4)
> # do stuff
> table[3][4].button(:index, 1).click
>
> This is convenient and often what casual users expect. Currently
> watir
> supports this to one level only.
>
> Once we have this, this gives us a platform that we can do several
> other
> things:
> a. invoke method in a separate process, so we never run into
> thread
> blocking problems again.
> b. invoke selenium or xcom/mozilla or another browser-driving
> technology
> instead of IE/COM
> c. attach a logger so we get cheap, decent, accurate logging
>
>
>
> _____________________
> Bret Pettichord
> www.pettichord.com
>
> _______________________________________________
> Wtr-general mailing list
> Wtr-general@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-general
>
_______________________________________________
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
_____________________
Bret Pettichord
www.pettichord.com
_______________________________________________
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
