Comments in-line, preceeded by Paul->
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bret Pettichord
Sent: 17 August 2005 23:05
To: [EMAIL PROTECTED]
Subject: Re: [Wtr-general] next steps
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).
Paul -> Great idea
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'.
Paul -> Yes, Id know id already written it, and named it wrong! But it
currently only applies to span/div. it should get moved into Element ( I
think that's whatis called now) so it applies to all html elements
> 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.
Paul -> yep, someone just enterd a feature request for this - the
example you give here wouldn't necessarily work for what I was thinking,
as there may be several textfields with that class
>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
> > [EMAIL PROTECTED]
> > http://rubyforge.org/mailman/listinfo/wtr-general
> >
>
>_______________________________________________
>Wtr-general mailing list
>[EMAIL PROTECTED]
>http://rubyforge.org/mailman/listinfo/wtr-general
_____________________
Bret Pettichord
www.pettichord.com
_______________________________________________
Wtr-general mailing list
[EMAIL PROTECTED]
http://rubyforge.org/mailman/listinfo/wtr-general
_______________________________________________
Wtr-general mailing list
[EMAIL PROTECTED]
http://rubyforge.org/mailman/listinfo/wtr-general
