From jeff.darklight at gmail.com  Tue Nov  1 20:20:29 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Tue, 1 Nov 2005 17:20:29 -0800
Subject: [Wtr-core] Fwd:  ... questions about Watir::ElementCollections
In-Reply-To: <b539c61e0511011720v5fcb4d1cnc2bf1e81e9ec8057@mail.gmail.com>
References: <b539c61e0510271627g17533d50u96028b461c8074f1@mail.gmail.com>
	<5.1.0.14.2.20051028001132.035dcee8@pop.gmail.com>
	<4361C06C.4060604@qantom.com>
	<b539c61e0510280736m3fc06066scd4f5b2a9b30b8c3@mail.gmail.com>
	<b539c61e0511011720v5fcb4d1cnc2bf1e81e9ec8057@mail.gmail.com>
Message-ID: <b539c61e0511011720q3d7f0ecs7167cc3170edd162@mail.gmail.com>

Sorry, sent this to Raghu only ... meant for the wtr-core list.

---------- Forwarded message ----------
From: Jeff Wood <jeff.darklight at gmail.com>
Date: Nov 1, 2005 5:20 PM
Subject: Re: [Wtr-core] ... questions about Watir::ElementCollections
To: Raghu Venkataramana <raghu at qantom.com>

I just thought of a REALLY cool way to way to do something like this...

How about adding a contains? method to our "element"

then you could do

ie.tableCell( :name, "foo" ).contains? ie.image( :name, "bar" )

or any other code similar to that.

I'd like to see the contains and then all of the Enumeration functions on
the collections

ie.tablecells.select
etc.

what do you think?

j.

On 10/28/05, Jeff Wood <jeff.darklight at gmail.com> wrote:
>
> There's a couple of pieces that would be cool ...
>  #1 - Putting things into a tree ... I don't think it would be extremely
> time expensive, since we could simplify what is in the "element" objects ...
> A few special object specific attribute wrappers, but the rest would be
> generic ... Simply a wrapper for the @ole ... with a method missing, and
> methods for each of the attributes ( easily parsable from the #html method
> ).
>   I'm just thinking we re-build the tree after "click", "set",
> "fire_event" ... etc. That ways it's up to date as the user does stuff.
>  But, what that would give us is the ability to do code like
>  needed_tables = $ie.tables.select { |currTable| currTable.has_link?(
> :text, /blah/ ) and currTable.has_link?( :text, /blahblah/ ) }
>  needed_tables.each do |curr|
>  # ... do stuff with each table.
> end
>  or
>   $ie.tables.each do |currTable|
>  currTable.rows.each do |currRow|
>  currRow.cells.each do |currCell|
>  .. do specific searching or whatever here.
>  .. but, you now have back history to see which table, and which row, and
> which cell you are in.
>  end
>  end
> end
> those kinds of things.
>  we always get questions like, * I want the button that's in the same
> table cell as the link "blah" * ... this would deal with it.
>  # click a button that is a sibling with a specific link...
> $ie.link( :text, /blah/ ).parent.button( :src, /foo/ ).click
>  plus, if it's done right, it would give us all of the Enumerable goodness
> ... imagine doing the following in IRB:
>  $ie.tables.sort_by { |curr| curr.accessKey }
>  or
>  $ie.tables.names.grep /mainTable/
>  or, if you're looking for a good hierarchy view ... just do a
>  puts $ie.elements.to_yaml
>  ... those kinds of things ...
>  Hope that makes sense ... I've started playing with an new tree of
> Web::Elements that should exhibit this kind of behavior ...
>  I'll post more .. but, I figured it was a good thing to get all of your
> feedback on. I respect the project and want to add to it, not fork off
> something seperate.
>  j.
>
>  On 10/27/05, Raghu Venkataramana <raghu at qantom.com > wrote:
> >
> > Bret Pettichord wrote:
> >
> > > At 12:26 AM 10/28/2005, Raghu Venkataramana wrote:
> > >
> > >> >I'd like Watir to dig through the html and build the object tree so
> > >> >that in memory is all of the Watir::Element derivatives for the
> > entire
> > >> >document.
> > >> >
> > >> >
> > >> I agree that it is a useful utility to have. It would make scripting
> > for
> > >> Watir a lot easier.
> > >
> > >
> > > Can you give examples of what you want to do?
> > >
> > > One thing that needs to be changed with Watir is that the collections
> > > objects should iterate over Watir objects rather than COM objects. I
> > > think this might give you what you need. But i need to know what
> > > problem you are trying to solve.
> >
> > Precisely what you said above. If there were to be some sort of a 'watir
> > tree' collection, that would make life easier. An example watir(ized)
> > representation for a html page could be
> >
> > body ---| title = New webpage; url=http://example.org/watir
> > | - image ; id = img1, alt=oneimage
> > | - table | id = tbl1
> > | - textfield; name=tf1; id=id_tf1
> > | - checkbox; name=cb1; id=id_cb1
> > | - image ; id = img2, alt=another
> > | .......
> > ......
> > | .......
> > | - table | id = tbl2
> > | .......
> > ......
> > | .......
> > | - link ; text = mylink; id=...
> >
> >
> > If such a representation is created internally when Watir loads a page,
> > then you could print out the objects in a more 'watir' like fashion. For
> > example, if you say show_images, it could show something like.
> >
> > ie(:title, "New webpage) -> image(:id=img1, :alt=oneimage)
> > ie(:title, "New webpage) -> table(:id=tbl1) -> image(:id=img2,
> > :alt=another)
> >
> > and so on.
> >
> > Raghu
> >
> > >
> > > Bret
> > >
> > >
> > > _____________________
> > > Bret Pettichord
> > > www.pettichord.com <http://www.pettichord.com>
> > >
> > >
> >
> >
> > --
> > Qantom Software
> >
> > http://www.qantom.com
> > Ph : 91-80-26799269 Xtn. 125
> > sip : raghu at sip411.com
> > --
> >
> >
>
>
> --
> " http://ruby-lang.org -- do you ruby?"
>
> Jeff Wood
>



--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood


--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051101/dcdeb43b/attachment.htm

From bret at pettichord.com  Wed Nov  2 01:23:36 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 02 Nov 2005 00:23:36 -0600
Subject: [Wtr-core] Fwd: Here's that new object model code I was talking
	about ...
Message-ID: <5.1.0.14.2.20051102000540.03732290@pop.gmail.com>

Jeff sent me this about a month ago, but i've only now had a chance to take 
a look at it. It bears on some of the things we've been discussing here 
recently, plus one of the purposes of this list is specifically to provide 
a forum to discuss proposals like this.

Any how, my first impression of this is that i'm not quite sure what 
problem it is meant to solve. I see a few clever ideas in here and i also 
see what i think are bugs. What i would rather see is an example of the 
kind of test that would use this library.

This is truly the point and value of TDD. First you describe the behavior 
that you want to support, then you worry about the implementation. So i 
would like to see more about the problem to be solved -- the tests that you 
want to write that motivate writing this library.

Another comment: in several ways this reminds me of Chris Morris's original 
IEController. Jeff, you should definitely take a look at it.

Another question: Why do you keep track of parent object? I never see this 
used anywhere.

It's not quite clear to me how you plan to specify page elements. Something 
like this?
   Web.Browser.all.select{|x| x.tagname == 'input' && x.type == 'text' && 
x.name == 'foo'}
One of the interim wrappers i created for the IEController supported syntax 
such as:
   ie.text_fields {|i| i.name == 'foo'}
We lost this with the Watir development and i'd always thought it would be 
good to add it back in, but there hasn't really been a compelling reason 
for it.

Other comments, etc are welcome.

Bret

Date: Wed, 28 Sep 2005 08:03:43 -0700
>From: Jeff Wood <jeff.darklight at gmail.com>
>To: Bret Pettichord <bret at pettichord.com>
>Subject: Here's that new object model code I was talking about ...
>
>  if you have time give it a review for me, please?
>
>It's not completely working, but I figured it was a start ... maybe
>good for ideas ... who knows.

_____________________
  Bret Pettichord
  www.pettichord.com
-------------- next part --------------

require 'win32ole'

class Window
    # implement window specific stuff like send-keys functionality & find/activate window
end

module Web

    class Base
        attr_reader :ole, :parent
        def initialize( oleObject, parentReference )
            @ole = oleObject
            @parent = parentReference
        end

        def method_missing( method, *args, &block )
            begin
                @ole.send( method, *args, &block )
            rescue
                getAttribute( method )
            end
        end

        def getAttribute( attributeName )
            @ole.getAttribute attributeName
        end
    end
    
    class Browser < Web::Base

        def initialize
			super( nil, nil )            
            @ole = WIN32OLE.new( "internetexplorer.application" )
            @ole.visible = "TRUE"
            ObjectSpace.define_finalizer( self, proc{ quit } )
        end

        def method_missing( method, *args, &block )
            begin
                super( method, *args, &block )
            rescue
                document.send( method, *args, &block )
            end
        end

        def quit
            @ole.quit
        end

        def actionComplete?
            @ole.ReadyState == 4 # IE constant for activity complete.
        end

        def waitForActionComplete
            while not actionComplete?
                sleep 1
            end
        end

        def navigate( url )
            @ole.navigate url
            waitForActionComplete
        end

        alias_method :goTo, :navigate

        def goHome
            @ole.GoHome
            waitForActionComplete
        end

        def goForward
            @ole.GoForward
            waitForActionComplete
        end

        def goBack
            @ole.GoBack
            waitForActionComplete
        end

        def validateRefreshLevel( refreshLevel )

            case refreshLevel
            when :normal
                valueValid = 0
            when :ifExpired
                valueValid = 1
            when :completely
                valueValid = 3
            else
                raise "Invalid Refresh Level Value: #{ refreshLevel }"
            end

        end

        # refresh( refreshLevel ) 
        # value should be :normal, :ifExpired, or :completely
        #
        # any other value will raise an exception
        def refresh( refreshLevel = :completely )
            @ole.Refresh2 validateRefreshLevel( refreshLevel )
            waitForActionComplete
        end

        def document
            Document.new( @ole.Document, self )
        end

    end

    class Document < Web::Base

        # TODO: Need to make sure this object reloads itself when things happen in the browser.

        # -- Document attributes --
        # activeElement
        # body
        # protocol
        # referrer
        # url
        # title
        # fileCreatedDate
        # fileModifiedDate
        # fileUpdatedDate
        # fileSize
        # lastUpdated

        # -- The following are collections -- 
        def all
            Web::Elements.new( @ole.all, self )
        end

        def anchors
            Web::Elements.new( @ole.anchors, self )
        end

        alias_method :links, :anchors

        def embeds
            Web::Elements.new( @ole.embeds, self )
        end

        def forms
            Web::Elements.new( @ole.forms, self )
        end

        def frames
            Web::Elements.new( @ole.frames, self )
        end

        def images
            Web::Elements.new( @ole.images, self )
        end

    end

    class Elements < Web::Base

        def initialize( oleCollection, parentObject )
            super( oleCollection, parentObject )
            @elements = []
            oleCollection.length.times do |iter|
                @elements << Web::Element.new( oleCollection.item( iter ), parentObject )
            end
        end

        def method_missing( method, *args, &block )
            @elements.send( method, *args, &block )
        end
    end

    class Element < Web::Base

        # tagName

        # innerText
        # innerHTML
        # outerText
        # outerHTML

        # click
        # fireEvent
        # scrollIntoView
        # sourceIndex

        # Core tag attributes ( getAttribute )
        # id
        # class
        # title
        # style
        # dir
        # lang
        # tabindex
        # accesskey

        # Optional tag attributes ( getAttribute )
        # name
        # value
        # src
        # href
        # alt
        # enabled
        # readonly

        # Container functionality
        def all
            Web::Elements.new( @ole.all, self )
        end

        def children
            Web::Elements.new( @ole.children, self )
        end

        # TODO: Add "flash" functionality
        
    end
    
end

From bret at pettichord.com  Wed Nov  2 13:55:41 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 02 Nov 2005 12:55:41 -0600
Subject: [Wtr-core] Fwd: Here's that new object model code I was talking
 about ...
In-Reply-To: <b539c61e0511012332n74194834o5e5eca78e8d9082c@mail.gmail.co
 m>
References: <5.1.0.14.2.20051102000540.03732290@pop.gmail.com>
	<5.1.0.14.2.20051102000540.03732290@pop.gmail.com>
Message-ID: <5.1.0.14.2.20051102125214.037c0888@pop.gmail.com>

Jeff,

I noticed that you only replied to me, not to the wtr-core group.

My point isn't to say that you should have written tests first. It's that i 
can't really assess your idea without knowing what you want to use it for.

That is fundamental to how Watir has been designed, and to how i assess 
suggestions.

Another way of saying this is that Watir was intended to be easy to use, 
not necessarily easy or clean or simple to implement.

Bret

At 01:32 AM 11/2/2005, you wrote:
>The point of including the parents was to allow traversal "up" from children
>
>yeah, I know I should have written tests first, but I started by simply 
>playing with Win32OLE.
>
>it just kinda stretched from there.
>
>My goal was a more ruby-ish way of digging around, and iterating through 
>collections of objects.
>
>Anyways, I'll look at the other project you mentioned, just showing my 
>thoughts ...
>
>and thanks for the feedback.
>
>j.
>
>
>On 11/1/05, Bret Pettichord 
><<mailto:bret at pettichord.com>bret at pettichord.com> wrote:
>Jeff sent me this about a month ago, but i've only now had a chance to take
>a look at it. It bears on some of the things we've been discussing here
>recently, plus one of the purposes of this list is specifically to provide
>a forum to discuss proposals like this.
>
>Any how, my first impression of this is that i'm not quite sure what
>problem it is meant to solve. I see a few clever ideas in here and i also
>see what i think are bugs. What i would rather see is an example of the
>kind of test that would use this library.
>
>This is truly the point and value of TDD. First you describe the behavior
>that you want to support, then you worry about the implementation. So i
>would like to see more about the problem to be solved -- the tests that you
>want to write that motivate writing this library.
>
>Another comment: in several ways this reminds me of Chris Morris's original
>IEController. Jeff, you should definitely take a look at it.
>
>Another question: Why do you keep track of parent object? I never see this
>used anywhere.
>
>It's not quite clear to me how you plan to specify page elements. Something
>like this?
>   Web.Browser.all.select{|x| x.tagname == 'input' && x.type == 'text' &&
><http://x.name>x.name == 'foo'}
>One of the interim wrappers i created for the IEController supported syntax
>such as:
>   ie.text_fields {|i| <http://i.name>i.name == 'foo'}
>We lost this with the Watir development and i'd always thought it would be
>good to add it back in, but there hasn't really been a compelling reason
>for it.
>
>Other comments, etc are welcome.
>
>Bret
>
>Date: Wed, 28 Sep 2005 08:03:43 -0700
> >From: Jeff Wood <<mailto:jeff.darklight at gmail.com>jeff.darklight at gmail.com>
> >To: Bret Pettichord <<mailto:bret at pettichord.com> bret at pettichord.com>
> >Subject: Here's that new object model code I was talking about ...
> >
> >  if you have time give it a review for me, please?
> >
> >It's not completely working, but I figured it was a start ... maybe
> >good for ideas ... who knows.
>
>_____________________
>Bret Pettichord
><http://www.pettichord.com>www.pettichord.com
>
>
>
>_______________________________________________
>Wtr-core mailing list
><mailto:Wtr-core at rubyforge.org>Wtr-core at rubyforge.org
>http://rubyforge.org/mailman/listinfo/wtr-core
>
>
>
>
>
>
>
>
>--
>"<http://ruby-lang.org>http://ruby-lang.org -- do you ruby?"
>
>Jeff Wood

_____________________
  Bret Pettichord
  www.pettichord.com


From jeff.darklight at gmail.com  Wed Nov  2 16:15:03 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Wed, 2 Nov 2005 13:15:03 -0800
Subject: [Wtr-core] Fwd: Here's that new object model code I was talking
	about ...
In-Reply-To: <5.1.0.14.2.20051102125214.037c0888@pop.gmail.com>
References: <5.1.0.14.2.20051102000540.03732290@pop.gmail.com>
	<5.1.0.14.2.20051102125214.037c0888@pop.gmail.com>
Message-ID: <b539c61e0511021315r6ddeba3dyb4968993af4efc1c@mail.gmail.com>

Gotcha.

I was looking at this as somebody who ISN'T new to programming in Ruby. I'm
a died in the wool 150% ruby phreak! So, the more I can use "the ruby way"
to build my tests & such, the happier I am.

I agree that all of the functionality in WATiR is useful, but it also hides
a lot of things that can just as easily be done with Ruby's built in
features. That was what made me start to think of coming up with a more
consistently featured object system.

so,

buttons.select { |c| c.name <http://c.name> == "blah" }.each { |button|
button.click }

...stuff like that...

ie.table_cells.reject { ... }

... those kinds of things ... things where you need to do stuff with larger
sets of things in a page, more than just find "that 1 thing" ...

...

ie.tablecells.select { |c| c.contains ie.image.find { |i|
i.name<http://i.name>== :blah } }

j.


On 11/2/05, Bret Pettichord <bret at pettichord.com> wrote:
>
> Jeff,
>
> I noticed that you only replied to me, not to the wtr-core group.
>
> My point isn't to say that you should have written tests first. It's that
> i
> can't really assess your idea without knowing what you want to use it for.
>
> That is fundamental to how Watir has been designed, and to how i assess
> suggestions.
>
> Another way of saying this is that Watir was intended to be easy to use,
> not necessarily easy or clean or simple to implement.
>
> Bret
>
> At 01:32 AM 11/2/2005, you wrote:
> >The point of including the parents was to allow traversal "up" from
> children
> >
> >yeah, I know I should have written tests first, but I started by simply
> >playing with Win32OLE.
> >
> >it just kinda stretched from there.
> >
> >My goal was a more ruby-ish way of digging around, and iterating through
> >collections of objects.
> >
> >Anyways, I'll look at the other project you mentioned, just showing my
> >thoughts ...
> >
> >and thanks for the feedback.
> >
> >j.
> >
> >
> >On 11/1/05, Bret Pettichord
> ><<mailto:bret at pettichord.com>bret at pettichord.com> wrote:
> >Jeff sent me this about a month ago, but i've only now had a chance to
> take
> >a look at it. It bears on some of the things we've been discussing here
> >recently, plus one of the purposes of this list is specifically to
> provide
> >a forum to discuss proposals like this.
> >
> >Any how, my first impression of this is that i'm not quite sure what
> >problem it is meant to solve. I see a few clever ideas in here and i also
> >see what i think are bugs. What i would rather see is an example of the
> >kind of test that would use this library.
> >
> >This is truly the point and value of TDD. First you describe the behavior
> >that you want to support, then you worry about the implementation. So i
> >would like to see more about the problem to be solved -- the tests that
> you
> >want to write that motivate writing this library.
> >
> >Another comment: in several ways this reminds me of Chris Morris's
> original
> >IEController. Jeff, you should definitely take a look at it.
> >
> >Another question: Why do you keep track of parent object? I never see
> this
> >used anywhere.
> >
> >It's not quite clear to me how you plan to specify page elements.
> Something
> >like this?
> > Web.Browser.all.select{|x| x.tagname == 'input' && x.type == 'text' &&
> ><http://x.name>x.name <http://x.name> == 'foo'}
> >One of the interim wrappers i created for the IEController supported
> syntax
> >such as:
> > ie.text_fields {|i| <http://i.name>i.name <http://i.name> == 'foo'}
> >We lost this with the Watir development and i'd always thought it would
> be
> >good to add it back in, but there hasn't really been a compelling reason
> >for it.
> >
> >Other comments, etc are welcome.
> >
> >Bret
> >
> >Date: Wed, 28 Sep 2005 08:03:43 -0700
> > >From: Jeff Wood <<mailto:jeff.darklight at gmail.com>
> jeff.darklight at gmail.com>
> > >To: Bret Pettichord <<mailto:bret at pettichord.com> bret at pettichord.com>
> > >Subject: Here's that new object model code I was talking about ...
> > >
> > > if you have time give it a review for me, please?
> > >
> > >It's not completely working, but I figured it was a start ... maybe
> > >good for ideas ... who knows.
> >
> >_____________________
> >Bret Pettichord
> ><http://www.pettichord.com>www.pettichord.com <http://www.pettichord.com>
> >
> >
> >
> >_______________________________________________
> >Wtr-core mailing list
> ><mailto:Wtr-core at rubyforge.org>Wtr-core at rubyforge.org
> >http://rubyforge.org/mailman/listinfo/wtr-core
> >
> >
> >
> >
> >
> >
> >
> >
> >--
> >"<http://ruby-lang.org>http://ruby-lang.org -- do you ruby?"
> >
> >Jeff Wood
>
> _____________________
> Bret Pettichord
> www.pettichord.com <http://www.pettichord.com>
>
>


--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051102/3f4a45f7/attachment.htm

From bret at pettichord.com  Wed Nov  2 17:46:05 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 02 Nov 2005 16:46:05 -0600
Subject: [Wtr-core] Fwd: Here's that new object model code I was talking
 about ...
In-Reply-To: <b539c61e0511021315r6ddeba3dyb4968993af4efc1c@mail.gmail.co
 m>
References: <5.1.0.14.2.20051102125214.037c0888@pop.gmail.com>
	<5.1.0.14.2.20051102000540.03732290@pop.gmail.com>
	<5.1.0.14.2.20051102125214.037c0888@pop.gmail.com>
Message-ID: <5.1.0.14.2.20051102164227.039b14c8@pop.gmail.com>

At 03:15 PM 11/2/2005, Jeff Wood wrote:
>buttons.select { |c| <http://c.name>c.name == "blah" }.each { |button| 
>button.click }

I'm not sure the point of this. If there is only one button named 'blah', 
then this seems like too much. But if there is more than one, it won't 
work. Because the second button probably won't still be on the button after 
the first one was clicked.


_____________________
  Bret Pettichord
  www.pettichord.com


From jeff.darklight at gmail.com  Wed Nov  2 18:39:20 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Wed, 2 Nov 2005 15:39:20 -0800
Subject: [Wtr-core] Fwd: Here's that new object model code I was talking
	about ...
In-Reply-To: <5.1.0.14.2.20051102164227.039b14c8@pop.gmail.com>
References: <5.1.0.14.2.20051102000540.03732290@pop.gmail.com>
	<5.1.0.14.2.20051102125214.037c0888@pop.gmail.com>
	<5.1.0.14.2.20051102164227.039b14c8@pop.gmail.com>
Message-ID: <b539c61e0511021539u693d64dbn14e60269c20d1217@mail.gmail.com>

The example was a bit contrite... I mean that it could give you heavy
selection criteria. Basically the goal was to be able to validate a number
of things at the same time ... an enabled checkbox with a specific class
assigned, and specific text ... etc ... multiple selection criteria... and
the ability to find things on the page based on other things in the page...

Like finding table cells that contains buttons with matching attributes...
so that you can then turn around and find text in those cells, etc.

... those are the kinds of things I'm talking about.

I've got data in table cells that I need to find... One of the only ways to
validate that I'm in the right cell is to find a link in the same cell...

... hope that makes sense.

j.

On 11/2/05, Bret Pettichord <bret at pettichord.com> wrote:
>
> At 03:15 PM 11/2/2005, Jeff Wood wrote:
> >buttons.select { |c| <http://c.name>c.name <http://c.name> == "blah"
> }.each { |button|
> >button.click }
>
> I'm not sure the point of this. If there is only one button named 'blah',
> then this seems like too much. But if there is more than one, it won't
> work. Because the second button probably won't still be on the button
> after
> the first one was clicked.
>
>
> _____________________
> Bret Pettichord
> www.pettichord.com <http://www.pettichord.com>
>
>


--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051102/6e135f8b/attachment.htm

From bret at pettichord.com  Wed Nov  2 19:03:47 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 02 Nov 2005 18:03:47 -0600
Subject: [Wtr-core] Fwd: Here's that new object model code I was talking
 about ...
In-Reply-To: <b539c61e0511021539u693d64dbn14e60269c20d1217@mail.gmail.co
 m>
References: <5.1.0.14.2.20051102164227.039b14c8@pop.gmail.com>
	<5.1.0.14.2.20051102000540.03732290@pop.gmail.com>
	<5.1.0.14.2.20051102125214.037c0888@pop.gmail.com>
	<5.1.0.14.2.20051102164227.039b14c8@pop.gmail.com>
Message-ID: <5.1.0.14.2.20051102175414.037b8ed0@pop.gmail.com>


>... hope that makes sense.

I'm not sure. Would adding support for using blocks as specifiers allow you 
to do what you are requesting?

 >Like finding table cells that contains buttons with matching 
attributes...  so >that you can then turn around and find text in those 
cells, etc.

   ie.cell{|c| c.button(:class, 'foo').exists?}.text

>I've got data in table cells that I need to find... One of the only ways 
>to validate that I'm in the right cell is to find a link in the same cell...

   ie.cell{|c| c.link(:text, 'foo').exists?}.text

This of course would be more or less the same as:

   ie.cells.select{|c| c.link(:text, 'foo').exists?}[0].text

Bret

_____________________
  Bret Pettichord
  www.pettichord.com


From bret at pettichord.com  Thu Nov  3 17:29:38 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Thu, 03 Nov 2005 16:29:38 -0600
Subject: [Wtr-core] Fwd: Re: Fwd: Here's that new object model code I was
 talking about ...
Message-ID: <5.1.0.14.2.20051103162833.03b2d4d8@pop.gmail.com>


>Date: Wed, 2 Nov 2005 16:24:51 -0800
>From: Jeff Wood <jeff.darklight at gmail.com>
>To: Bret Pettichord <bret at pettichord.com>
>Subject: Re: [Wtr-core] Fwd: Here's that new object model code I was 
>talking about ...
>
>Yeah, that would work ... and be much more ruby-ish.
>
>;)  good idea.
>
>j.
>
>On 11/2/05, Bret Pettichord 
><<mailto:bret at pettichord.com>bret at pettichord.com> wrote:
>>
>> >... hope that makes sense.
>>
>>I'm not sure. Would adding support for using blocks as specifiers allow you
>>to do what you are requesting?
>>
>> >Like finding table cells that contains buttons with matching
>>attributes...  so >that you can then turn around and find text in those
>>cells, etc.
>>
>>    ie.cell{|c| c.button(:class, 'foo').exists?}.text
>>
>> >I've got data in table cells that I need to find... One of the only ways
>> >to validate that I'm in the right cell is to find a link in the same 
>> cell...
>>
>>    ie.cell{|c| c.link(:text, 'foo').exists?}.text
>>
>>This of course would be more or less the same as:
>>
>>    ie.cells.select{|c| c.link(:text, 'foo').exists?}[0].text
>>
>>Bret
>>
>>_____________________
>>   Bret Pettichord
>>   <http://www.pettichord.com>www.pettichord.com
>
>
>
>--
>"http://ruby-lang.org -- do you ruby?"
>
>Jeff Wood

_____________________
  Bret Pettichord
  www.pettichord.com


From bret at pettichord.com  Thu Nov 10 00:20:37 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 09 Nov 2005 23:20:37 -0600
Subject: [Wtr-core] Fwd: [Wtr-general] New Watir Wiki, was Re:  FAQ Update
Message-ID: <5.1.0.14.2.20051109232017.03b3a7f0@pop.gmail.com>

Thoughts?

>Date: Tue, 08 Nov 2005 00:54:23 -0600
>To: wtr-general at rubyforge.org
>From: Bret Pettichord <bret at pettichord.com>
>Subject: [Wtr-general] New Watir Wiki, was Re:  FAQ Update
>
>I'm very interested in Sy's proposal (below) to host the Watir project wiki
>using Media Wiki.
>
>I've used Wikipedia before, and i did find it to be a pretty good system. I
>don't have any particular attachment to what we are using now, which is
>just what rubyforge provides. I'm particular interested to know the views
>of the people who've made a lot of contibutions to our wiki.
>
>My only concern is that if we have usernames to access, it would be nice if
>we could recycle the rubyforge usernames, just because that would make it
>easier for our contributors. But i'm not sure if that is really possible.
>
>Comments?
>
>Bret
>
>At 04:45 PM 11/6/2005, Sy Ali wrote:
> >On 11/5/05, Bret Pettichord <bret at pettichord.com> wrote:
> > > At 03:46 PM 11/4/2005, Sy Ali wrote:
> > > >I'd still rather like to update the entire wiki by
> > > >migrating it to mediawiki.  It was rather annoying to have had to wade
> > > >through that FAQ the few times that I did in order to clean it up
> > > >somewhat (and also answer my own questions).
> > >
> > > Thanks for cleaning it up. It looks a lot bettter.
> > >
> > > We are always open to specific proposals. Why would media wiki be better?
> > > Where would it be hosted?
> >
> >My main issue with the existing wiki is their markup language.  The
> >insistance of "CamelCase" links forces broken english titles and poor
> >sentances and is an eyesore to edit.
> >
> >The main benefits of mediawiki would be the various different skins.
> >I'm a particular fan of the default skin.  It's quite beautiful.  This
> >is the first and foremost thing that everyday users would see.  The
> >second would be the much nicer organization of the information.  From
> >experience, I can say that it's been intuitive to organize and
> >maintain a lot of information within a mediawiki installation.
> >
> >On the inside, the editing is very easy (the markup language is good).
> >  It's extremely nice to be able to edit just a section of a page.. one
> >doesn't get lost on more complecated pages like a FAQ.  Automatic
> >table of contents is nice.  The templating engine allows for easy
> >re-use of snippets of information.  Adding inline images is trivial.
> >
> >For more technical reasons, mediawiki is very easy to update and
> >maintain.  Updating it amounts to unpacking the new tarball over the
> >previous directory and running "php update.php" (or without ssh
> >access, it's still quite easy).  It's extremely easy to supervise,
> >with controls for viewing recent changes and the lke.
> >
> >For more social reasons, MediaWiki is wildly popular and in my mind
> >proved as an excellent tool because of its use for the Wikipedia.
> >This is what would assure continued development.. there are a lot of
> >interested people.
> >
> >
> >My only warnings are to require usernames for editing, to use the
> >spamblacklist extension and to include a one-liner regex to ban
> >certain types of content.  I can provide help with these things.
> >
> >If hosting is an issue, I'd be pleased to host it with my resources..
> >but it'll go anywhere php/mysql does.
> >
> >Curiously, it looks like the markup language is almost the same from
> >the existing wiki to mediawiki.  This means that it would be nearly
> >trivial to hand-port the content from the existing wiki to a mediawiki
> >installation.  Yes, I would be willing to do this and unless you've
> >got hundreds of pages of content I could get it done within two weeks.
> >  This would include the original wiki's content as well.
> >
> >My own wiki:
> >http://jrandomhacker.info
> >http://jrandomhacker.info/MediaWiki
> >
> >I also help maintain two other wikis:
> >My local Linux user group (GTALUG):
> >http://gtalug.org
> >
> >My local Ruby user group (TRUG):
> >http://trug.stok.co.uk/wiki/
> >soon to be http://trug.ca
> >
> >I've set up MediaWiki for my old work and my current business.  This
> >is after a long and tiring history with a few other wikis.  MediaWiki
> >has been amazing.
> >
> >
> >In the meantime, I intend to open up a Watir-specific section in TRUG
> >since I've just begun working with watir and need to begin a resource
> >and code repository.  Sorry for being long-winded.. but I just got
> >back from our meeting and am revved up.  =)
> >
> >
> >Sy,
> >
> >_______________________________________________
> >Wtr-general mailing list
> >Wtr-general at rubyforge.org
> >http://rubyforge.org/mailman/listinfo/wtr-general
>
>_____________________
>   Bret Pettichord
>   www.pettichord.com
>
>_______________________________________________
>Wtr-general mailing list
>Wtr-general at rubyforge.org
>http://rubyforge.org/mailman/listinfo/wtr-general

_____________________
  Bret Pettichord
  www.pettichord.com


From raghu at qantom.com  Thu Nov 10 01:24:57 2005
From: raghu at qantom.com (Raghu Venkataramana)
Date: Thu, 10 Nov 2005 11:54:57 +0530
Subject: [Wtr-core] Fwd: [Wtr-general] New Watir Wiki,
	was Re:  FAQ Update
In-Reply-To: <5.1.0.14.2.20051109232017.03b3a7f0@pop.gmail.com>
References: <5.1.0.14.2.20051109232017.03b3a7f0@pop.gmail.com>
Message-ID: <4372E7B9.2030207@qantom.com>

Bret Pettichord wrote:

>Thoughts?
>
>  
>
>>Date: Tue, 08 Nov 2005 00:54:23 -0600
>>To: wtr-general at rubyforge.org
>>From: Bret Pettichord <bret at pettichord.com>
>>Subject: [Wtr-general] New Watir Wiki, was Re:  FAQ Update
>>
>>I'm very interested in Sy's proposal (below) to host the Watir project wiki
>>using Media Wiki.
>>
>>I've used Wikipedia before, and i did find it to be a pretty good system. I
>>don't have any particular attachment to what we are using now, which is
>>just what rubyforge provides. I'm particular interested to know the views
>>of the people who've made a lot of contibutions to our wiki.
>>    
>>
+1.
I work on a project that uses a media-wiki powered wiki for its content 
management and it sounds good.

>>My only concern is that if we have usernames to access, it would be nice if
>>we could recycle the rubyforge usernames, just because that would make it
>>easier for our contributors. But i'm not sure if that is really possible.
>>    
>>
I personally dont have any objections in recycling usernames - simply 
because it is being done for the same
purpose that the user previously registered himself for. However there 
may be others who strongly
oppose their details being used without consent. May be sending out an 
invitation (just as we did for this
group) asking users to register to the new wiki ?

Just my 2 cents.

Raghu

>>Comments?
>>
>>Bret
>>
>>At 04:45 PM 11/6/2005, Sy Ali wrote:
>>    
>>
>>>On 11/5/05, Bret Pettichord <bret at pettichord.com> wrote:
>>>      
>>>
>>>>At 03:46 PM 11/4/2005, Sy Ali wrote:
>>>>        
>>>>
>>>>>I'd still rather like to update the entire wiki by
>>>>>migrating it to mediawiki.  It was rather annoying to have had to wade
>>>>>through that FAQ the few times that I did in order to clean it up
>>>>>somewhat (and also answer my own questions).
>>>>>          
>>>>>
>>>>Thanks for cleaning it up. It looks a lot bettter.
>>>>
>>>>We are always open to specific proposals. Why would media wiki be better?
>>>>Where would it be hosted?
>>>>        
>>>>
>>>My main issue with the existing wiki is their markup language.  The
>>>insistance of "CamelCase" links forces broken english titles and poor
>>>sentances and is an eyesore to edit.
>>>
>>>The main benefits of mediawiki would be the various different skins.
>>>I'm a particular fan of the default skin.  It's quite beautiful.  This
>>>is the first and foremost thing that everyday users would see.  The
>>>second would be the much nicer organization of the information.  From
>>>experience, I can say that it's been intuitive to organize and
>>>maintain a lot of information within a mediawiki installation.
>>>
>>>On the inside, the editing is very easy (the markup language is good).
>>> It's extremely nice to be able to edit just a section of a page.. one
>>>doesn't get lost on more complecated pages like a FAQ.  Automatic
>>>table of contents is nice.  The templating engine allows for easy
>>>re-use of snippets of information.  Adding inline images is trivial.
>>>
>>>For more technical reasons, mediawiki is very easy to update and
>>>maintain.  Updating it amounts to unpacking the new tarball over the
>>>previous directory and running "php update.php" (or without ssh
>>>access, it's still quite easy).  It's extremely easy to supervise,
>>>with controls for viewing recent changes and the lke.
>>>
>>>For more social reasons, MediaWiki is wildly popular and in my mind
>>>proved as an excellent tool because of its use for the Wikipedia.
>>>This is what would assure continued development.. there are a lot of
>>>interested people.
>>>
>>>
>>>My only warnings are to require usernames for editing, to use the
>>>spamblacklist extension and to include a one-liner regex to ban
>>>certain types of content.  I can provide help with these things.
>>>
>>>If hosting is an issue, I'd be pleased to host it with my resources..
>>>but it'll go anywhere php/mysql does.
>>>
>>>Curiously, it looks like the markup language is almost the same from
>>>the existing wiki to mediawiki.  This means that it would be nearly
>>>trivial to hand-port the content from the existing wiki to a mediawiki
>>>installation.  Yes, I would be willing to do this and unless you've
>>>got hundreds of pages of content I could get it done within two weeks.
>>> This would include the original wiki's content as well.
>>>
>>>My own wiki:
>>>http://jrandomhacker.info
>>>http://jrandomhacker.info/MediaWiki
>>>
>>>I also help maintain two other wikis:
>>>My local Linux user group (GTALUG):
>>>http://gtalug.org
>>>
>>>My local Ruby user group (TRUG):
>>>http://trug.stok.co.uk/wiki/
>>>soon to be http://trug.ca
>>>
>>>I've set up MediaWiki for my old work and my current business.  This
>>>is after a long and tiring history with a few other wikis.  MediaWiki
>>>has been amazing.
>>>
>>>
>>>In the meantime, I intend to open up a Watir-specific section in TRUG
>>>since I've just begun working with watir and need to begin a resource
>>>and code repository.  Sorry for being long-winded.. but I just got
>>>back from our meeting and am revved up.  =)
>>>
>>>
>>>Sy,
>>>
>>>_______________________________________________
>>>Wtr-general mailing list
>>>Wtr-general at rubyforge.org
>>>http://rubyforge.org/mailman/listinfo/wtr-general
>>>      
>>>
>>_____________________
>>  Bret Pettichord
>>  www.pettichord.com
>>
>>_______________________________________________
>>Wtr-general mailing list
>>Wtr-general at rubyforge.org
>>http://rubyforge.org/mailman/listinfo/wtr-general
>>    
>>
>
>_____________________
>  Bret Pettichord
>  www.pettichord.com
>
>_______________________________________________
>Wtr-core mailing list
>Wtr-core at rubyforge.org
>http://rubyforge.org/mailman/listinfo/wtr-core
>
>  
>


-- 
Qantom Software

http://www.qantom.com
Ph : 91-80-26799269 Xtn. 125
sip : raghu at sip411.com
--


From esh at qualitytree.com  Thu Nov 10 09:51:39 2005
From: esh at qualitytree.com (Elisabeth Hendrickson)
Date: Thu, 10 Nov 2005 06:51:39 -0800
Subject: [Wtr-core] Firefox support plans?
Message-ID: <E1EaDmD-0004vZ-F5@smtpauth07.mail.atl.earthlink.net>

Hey all,

Anybody have any news on porting Watir to Firefox?

I ask because I'm working on a project where we (gasp) aren't supporting
IE...at least for our first release we're only supporting Firefox.  It's a
javascript-heavy Web 2.0 app built on Rails that allows users to drag and
drop stuff around the screen.  Cool stuff, but very hard to test in an
automated fashion.  We're using Test::Unit and JSUnit for unit testing, but
we need an automated acceptance test solution.  My preference would be to
use Watir, but the IE-only thing is making that impossible.

I'm looking at using Selenium.  But I thought I'd check in and see if
anyone's ported Watir to FF yet.  So...any news?

If not...one of my colleagues (Rob Mee, for those who know him) suggested we
should put out a bid on RentaCoder to see if we can get someone to do the
first version of the port for cheap.  Would anyone be interested in going in
on a bid to get the first version done?

Elisabeth

---------------------------
Elisabeth Hendrickson
Quality Tree Software, Inc.
http://www.qualitytree.com
--------------------------- 



From bret at pettichord.com  Thu Nov 10 13:01:33 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Thu, 10 Nov 2005 12:01:33 -0600
Subject: [Wtr-core] Firefox support plans?
In-Reply-To: <E1EaDmD-0004vZ-F5@smtpauth07.mail.atl.earthlink.net>
Message-ID: <5.1.0.14.2.20051110115914.03b3fcc8@pop.gmail.com>

I suggest you use rubySelenium to drive Firefox. That way you get to use 
ruby and it works today with Firefox.

With time, i wonder if we won't be refactoring rubySelenium to look like watir.

I suspect that initial port (when and if it occurs) of Watir to Firefox 
using XCOM will uncover XCOM gaps that will need to be fixed in the Mozilla 
codebase.

Bret

At 08:51 AM 11/10/2005, Elisabeth Hendrickson wrote:
>Hey all,
>
>Anybody have any news on porting Watir to Firefox?
>
>I ask because I'm working on a project where we (gasp) aren't supporting
>IE...at least for our first release we're only supporting Firefox.  It's a
>javascript-heavy Web 2.0 app built on Rails that allows users to drag and
>drop stuff around the screen.  Cool stuff, but very hard to test in an
>automated fashion.  We're using Test::Unit and JSUnit for unit testing, but
>we need an automated acceptance test solution.  My preference would be to
>use Watir, but the IE-only thing is making that impossible.
>
>I'm looking at using Selenium.  But I thought I'd check in and see if
>anyone's ported Watir to FF yet.  So...any news?
>
>If not...one of my colleagues (Rob Mee, for those who know him) suggested we
>should put out a bid on RentaCoder to see if we can get someone to do the
>first version of the port for cheap.  Would anyone be interested in going in
>on a bid to get the first version done?
>
>Elisabeth
>
>---------------------------
>Elisabeth Hendrickson
>Quality Tree Software, Inc.
>http://www.qualitytree.com
>---------------------------
>
>
>_______________________________________________
>Wtr-core mailing list
>Wtr-core at rubyforge.org
>http://rubyforge.org/mailman/listinfo/wtr-core

_____________________
  Bret Pettichord
  www.pettichord.com


From christopher.mcmahon at gmail.com  Thu Nov 10 13:23:48 2005
From: christopher.mcmahon at gmail.com (Chris McMahon)
Date: Thu, 10 Nov 2005 12:23:48 -0600
Subject: [Wtr-core] Firefox support plans?
In-Reply-To: <5.1.0.14.2.20051110115914.03b3fcc8@pop.gmail.com>
References: <E1EaDmD-0004vZ-F5@smtpauth07.mail.atl.earthlink.net>
	<5.1.0.14.2.20051110115914.03b3fcc8@pop.gmail.com>
Message-ID: <72799cd70511101023k4e22b1d6h3d80176a3d7b6e87@mail.gmail.com>

On 11/10/05, Bret Pettichord <bret at pettichord.com> wrote:
> I suggest you use rubySelenium to drive Firefox. That way you get to use
> ruby and it works today with Firefox.


And hope you don't need to manipulate any frames.
-Chris


From bret at pettichord.com  Thu Nov 10 13:43:50 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Thu, 10 Nov 2005 12:43:50 -0600
Subject: [Wtr-core] Firefox support plans?
In-Reply-To: <72799cd70511101023k4e22b1d6h3d80176a3d7b6e87@mail.gmail.co
 m>
References: <5.1.0.14.2.20051110115914.03b3fcc8@pop.gmail.com>
	<E1EaDmD-0004vZ-F5@smtpauth07.mail.atl.earthlink.net>
	<5.1.0.14.2.20051110115914.03b3fcc8@pop.gmail.com>
Message-ID: <5.1.0.14.2.20051110124213.03c22d58@pop.gmail.com>

At 12:23 PM 11/10/2005, Chris McMahon wrote:
>And hope you don't need to manipulate any frames.

Actually i think adding frame support to Selenium would probably be easier 
than porting Watir to Firefox.

In any case, Elisabeth said she was working with Rob Mee, who i trust to 
avoid frames at all costs.


_____________________
  Bret Pettichord
  www.pettichord.com


From jeff.darklight at gmail.com  Thu Nov 10 15:55:33 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Thu, 10 Nov 2005 12:55:33 -0800
Subject: [Wtr-core] Fwd: [Wtr-general] New Watir Wiki, was Re: FAQ Update
In-Reply-To: <4372E7B9.2030207@qantom.com>
References: <5.1.0.14.2.20051109232017.03b3a7f0@pop.gmail.com>
	<4372E7B9.2030207@qantom.com>
Message-ID: <b539c61e0511101255l73c038c4m6b87014a21c3810d@mail.gmail.com>

... Sorry if this sounds purist, but I believe that we should be eating our
own dogfood here.... If it's about a ruby-based project, then put a
ruby-based site on top of it.

I spent too many years dealing with the MUCK of PHP, I'd rather leave it out
of my life.

j.

On 11/9/05, Raghu Venkataramana <raghu at qantom.com> wrote:
>
> Bret Pettichord wrote:
>
> >Thoughts?
> >
> >
> >
> >>Date: Tue, 08 Nov 2005 00:54:23 -0600
> >>To: wtr-general at rubyforge.org
> >>From: Bret Pettichord <bret at pettichord.com>
> >>Subject: [Wtr-general] New Watir Wiki, was Re: FAQ Update
> >>
> >>I'm very interested in Sy's proposal (below) to host the Watir project
> wiki
> >>using Media Wiki.
> >>
> >>I've used Wikipedia before, and i did find it to be a pretty good
> system. I
> >>don't have any particular attachment to what we are using now, which is
> >>just what rubyforge provides. I'm particular interested to know the
> views
> >>of the people who've made a lot of contibutions to our wiki.
> >>
> >>
> +1.
> I work on a project that uses a media-wiki powered wiki for its content
> management and it sounds good.
>
> >>My only concern is that if we have usernames to access, it would be nice
> if
> >>we could recycle the rubyforge usernames, just because that would make
> it
> >>easier for our contributors. But i'm not sure if that is really
> possible.
> >>
> >>
> I personally dont have any objections in recycling usernames - simply
> because it is being done for the same
> purpose that the user previously registered himself for. However there
> may be others who strongly
> oppose their details being used without consent. May be sending out an
> invitation (just as we did for this
> group) asking users to register to the new wiki ?
>
> Just my 2 cents.
>
> Raghu
>
> >>Comments?
> >>
> >>Bret
> >>
> >>At 04:45 PM 11/6/2005, Sy Ali wrote:
> >>
> >>
> >>>On 11/5/05, Bret Pettichord <bret at pettichord.com> wrote:
> >>>
> >>>
> >>>>At 03:46 PM 11/4/2005, Sy Ali wrote:
> >>>>
> >>>>
> >>>>>I'd still rather like to update the entire wiki by
> >>>>>migrating it to mediawiki. It was rather annoying to have had to wade
> >>>>>through that FAQ the few times that I did in order to clean it up
> >>>>>somewhat (and also answer my own questions).
> >>>>>
> >>>>>
> >>>>Thanks for cleaning it up. It looks a lot bettter.
> >>>>
> >>>>We are always open to specific proposals. Why would media wiki be
> better?
> >>>>Where would it be hosted?
> >>>>
> >>>>
> >>>My main issue with the existing wiki is their markup language. The
> >>>insistance of "CamelCase" links forces broken english titles and poor
> >>>sentances and is an eyesore to edit.
> >>>
> >>>The main benefits of mediawiki would be the various different skins.
> >>>I'm a particular fan of the default skin. It's quite beautiful. This
> >>>is the first and foremost thing that everyday users would see. The
> >>>second would be the much nicer organization of the information. From
> >>>experience, I can say that it's been intuitive to organize and
> >>>maintain a lot of information within a mediawiki installation.
> >>>
> >>>On the inside, the editing is very easy (the markup language is good).
> >>> It's extremely nice to be able to edit just a section of a page.. one
> >>>doesn't get lost on more complecated pages like a FAQ. Automatic
> >>>table of contents is nice. The templating engine allows for easy
> >>>re-use of snippets of information. Adding inline images is trivial.
> >>>
> >>>For more technical reasons, mediawiki is very easy to update and
> >>>maintain. Updating it amounts to unpacking the new tarball over the
> >>>previous directory and running "php update.php" (or without ssh
> >>>access, it's still quite easy). It's extremely easy to supervise,
> >>>with controls for viewing recent changes and the lke.
> >>>
> >>>For more social reasons, MediaWiki is wildly popular and in my mind
> >>>proved as an excellent tool because of its use for the Wikipedia.
> >>>This is what would assure continued development.. there are a lot of
> >>>interested people.
> >>>
> >>>
> >>>My only warnings are to require usernames for editing, to use the
> >>>spamblacklist extension and to include a one-liner regex to ban
> >>>certain types of content. I can provide help with these things.
> >>>
> >>>If hosting is an issue, I'd be pleased to host it with my resources..
> >>>but it'll go anywhere php/mysql does.
> >>>
> >>>Curiously, it looks like the markup language is almost the same from
> >>>the existing wiki to mediawiki. This means that it would be nearly
> >>>trivial to hand-port the content from the existing wiki to a mediawiki
> >>>installation. Yes, I would be willing to do this and unless you've
> >>>got hundreds of pages of content I could get it done within two weeks.
> >>> This would include the original wiki's content as well.
> >>>
> >>>My own wiki:
> >>>http://jrandomhacker.info
> >>>http://jrandomhacker.info/MediaWiki
> >>>
> >>>I also help maintain two other wikis:
> >>>My local Linux user group (GTALUG):
> >>>http://gtalug.org
> >>>
> >>>My local Ruby user group (TRUG):
> >>>http://trug.stok.co.uk/wiki/
> >>>soon to be http://trug.ca
> >>>
> >>>I've set up MediaWiki for my old work and my current business. This
> >>>is after a long and tiring history with a few other wikis. MediaWiki
> >>>has been amazing.
> >>>
> >>>
> >>>In the meantime, I intend to open up a Watir-specific section in TRUG
> >>>since I've just begun working with watir and need to begin a resource
> >>>and code repository. Sorry for being long-winded.. but I just got
> >>>back from our meeting and am revved up. =)
> >>>
> >>>
> >>>Sy,
> >>>
> >>>_______________________________________________
> >>>Wtr-general mailing list
> >>>Wtr-general at rubyforge.org
> >>>http://rubyforge.org/mailman/listinfo/wtr-general
> >>>
> >>>
> >>_____________________
> >> Bret Pettichord
> >> www.pettichord.com <http://www.pettichord.com>
> >>
> >>_______________________________________________
> >>Wtr-general mailing list
> >>Wtr-general at rubyforge.org
> >>http://rubyforge.org/mailman/listinfo/wtr-general
> >>
> >>
> >
> >_____________________
> > Bret Pettichord
> > www.pettichord.com <http://www.pettichord.com>
> >
> >_______________________________________________
> >Wtr-core mailing list
> >Wtr-core at rubyforge.org
> >http://rubyforge.org/mailman/listinfo/wtr-core
> >
> >
> >
>
>
> --
> Qantom Software
>
> http://www.qantom.com
> Ph : 91-80-26799269 Xtn. 125
> sip : raghu at sip411.com
> --
>
> _______________________________________________
> Wtr-core mailing list
> Wtr-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-core
>



--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051110/2f98c4ce/attachment-0001.htm

From bret at pettichord.com  Sat Nov 12 15:20:34 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Sat, 12 Nov 2005 14:20:34 -0600
Subject: [Wtr-core] Fwd: [Wtr-general] New Watir Wiki,
 was Re: FAQ  Update
In-Reply-To: <b539c61e0511101255l73c038c4m6b87014a21c3810d@mail.gmail.co
 m>
References: <4372E7B9.2030207@qantom.com>
	<5.1.0.14.2.20051109232017.03b3a7f0@pop.gmail.com>
	<4372E7B9.2030207@qantom.com>
Message-ID: <5.1.0.14.2.20051112141808.0292c768@pop.gmail.com>

We have a proposal to host our wiki using better technology than we are 
currently using. (Is this in question?)

The current wiki is not Ruby-based, despite being hosted by rubyforge.org.

Unless someone else is offering to set things up on a Ruby-based wiki, i'm 
inclined to accept Sy's offer.

Bret

At 02:55 PM 11/10/2005, Jeff Wood wrote:
>... Sorry if this sounds purist, but I believe that we should be eating 
>our own dogfood here.... If it's about a ruby-based project, then put a 
>ruby-based site on top of it.
>
>I spent too many years dealing with the MUCK of PHP, I'd rather leave it 
>out of my life.
>
>j.
>
>On 11/9/05, Raghu Venkataramana 
><<mailto:raghu at qantom.com>raghu at qantom.com> wrote:
>>Bret Pettichord wrote:
>>
>> >Thoughts?
>>
>> >
>> >>Date: Tue, 08 Nov 2005 00:54:23 -0600
>> >>To: <mailto:wtr-general at rubyforge.org>wtr-general at rubyforge.org
>> >>From: Bret Pettichord < <mailto:bret at pettichord.com>bret at pettichord.com>
>> >>Subject: [Wtr-general] New Watir Wiki, was Re:  FAQ Update
>> >>
>> >>I'm very interested in Sy's proposal (below) to host the Watir project 
>> wiki
>> >>using Media Wiki.
>> >>
>> >>I've used Wikipedia before, and i did find it to be a pretty good 
>> system. I
>> >>don't have any particular attachment to what we are using now, which is
>> >>just what rubyforge provides. I'm particular interested to know the views
>> >>of the people who've made a lot of contibutions to our wiki.
>> >>
>> >>
>>+1.
>>I work on a project that uses a media-wiki powered wiki for its content
>>management and it sounds good.
>>
>> >>My only concern is that if we have usernames to access, it would be 
>> nice if
>> >>we could recycle the rubyforge usernames, just because that would make it
>> >>easier for our contributors. But i'm not sure if that is really possible.
>> >>
>> >>
>>I personally dont have any objections in recycling usernames - simply
>>because it is being done for the same
>>purpose that the user previously registered himself for. However there
>>may be others who strongly
>>oppose their details being used without consent. May be sending out an
>>invitation (just as we did for this
>>group) asking users to register to the new wiki ?
>>
>>Just my 2 cents.
>>
>>Raghu
>>
>> >>Comments?
>> >>
>> >>Bret
>> >>
>> >>At 04:45 PM 11/6/2005, Sy Ali wrote:
>> >>
>> >>
>> >>>On 11/5/05, Bret Pettichord 
>> <<mailto:bret at pettichord.com>bret at pettichord.com> wrote:
>> >>>
>> >>>
>> >>>>At 03:46 PM 11/4/2005, Sy Ali wrote:
>> >>>>
>> >>>>
>> >>>>>I'd still rather like to update the entire wiki by
>> >>>>>migrating it to mediawiki.  It was rather annoying to have had to wade
>> >>>>>through that FAQ the few times that I did in order to clean it up
>> >>>>>somewhat (and also answer my own questions).
>> >>>>>
>> >>>>>
>> >>>>Thanks for cleaning it up. It looks a lot bettter.
>> >>>>
>> >>>>We are always open to specific proposals. Why would media wiki be 
>> better?
>> >>>>Where would it be hosted?
>> >>>>
>> >>>>
>> >>>My main issue with the existing wiki is their markup language.  The
>> >>>insistance of "CamelCase" links forces broken english titles and poor
>> >>>sentances and is an eyesore to edit.
>> >>>
>> >>>The main benefits of mediawiki would be the various different skins.
>> >>>I'm a particular fan of the default skin.  It's quite beautiful.  This
>> >>>is the first and foremost thing that everyday users would see.  The
>> >>>second would be the much nicer organization of the information.  From
>> >>>experience, I can say that it's been intuitive to organize and
>> >>>maintain a lot of information within a mediawiki installation.
>> >>>
>> >>>On the inside, the editing is very easy (the markup language is good).
>> >>> It's extremely nice to be able to edit just a section of a page.. one
>> >>>doesn't get lost on more complecated pages like a FAQ.  Automatic
>> >>>table of contents is nice.  The templating engine allows for easy
>> >>>re-use of snippets of information.  Adding inline images is trivial.
>> >>>
>> >>>For more technical reasons, mediawiki is very easy to update and
>> >>>maintain.  Updating it amounts to unpacking the new tarball over the
>> >>>previous directory and running "php update.php" (or without ssh
>> >>>access, it's still quite easy).  It's extremely easy to supervise,
>> >>>with controls for viewing recent changes and the lke.
>> >>>
>> >>>For more social reasons, MediaWiki is wildly popular and in my mind
>> >>>proved as an excellent tool because of its use for the Wikipedia.
>> >>>This is what would assure continued development.. there are a lot of
>> >>>interested people.
>> >>>
>> >>>
>> >>>My only warnings are to require usernames for editing, to use the
>> >>>spamblacklist extension and to include a one-liner regex to ban
>> >>>certain types of content.  I can provide help with these things.
>> >>>
>> >>>If hosting is an issue, I'd be pleased to host it with my resources..
>> >>>but it'll go anywhere php/mysql does.
>> >>>
>> >>>Curiously, it looks like the markup language is almost the same from
>> >>>the existing wiki to mediawiki.  This means that it would be nearly
>> >>>trivial to hand-port the content from the existing wiki to a mediawiki
>> >>>installation.  Yes, I would be willing to do this and unless you've
>> >>>got hundreds of pages of content I could get it done within two weeks.
>> >>> This would include the original wiki's content as well.
>> >>>
>> >>>My own wiki:
>> >>> http://jrandomhacker.info
>> >>><http://jrandomhacker.info/MediaWiki>http://jrandomhacker.info/MediaWiki
>> >>>
>> >>>I also help maintain two other wikis:
>> >>>My local Linux user group (GTALUG):
>> >>><http://gtalug.org>http://gtalug.org
>> >>>
>> >>>My local Ruby user group (TRUG):
>> >>><http://trug.stok.co.uk/wiki/>http://trug.stok.co.uk/wiki/
>> >>>soon to be <http://trug.ca>http://trug.ca
>> >>>
>> >>>I've set up MediaWiki for my old work and my current business.  This
>> >>>is after a long and tiring history with a few other wikis.  MediaWiki
>> >>>has been amazing.
>> >>>
>> >>>
>> >>>In the meantime, I intend to open up a Watir-specific section in TRUG
>> >>>since I've just begun working with watir and need to begin a resource
>> >>>and code repository.  Sorry for being long-winded.. but I just got
>> >>>back from our meeting and am revved up.  =)
>> >>>
>> >>>
>> >>>Sy,
>> >>>
>> >>>_______________________________________________
>> >>>Wtr-general mailing list
>> >>><mailto:Wtr-general at rubyforge.org>Wtr-general at rubyforge.org
>> >>>http://rubyforge.org/mailman/listinfo/wtr-general
>> >>>
>> >>>
>> >>_____________________
>> >>  Bret Pettichord
>> >>  <http://www.pettichord.com>www.pettichord.com
>> >>
>> >>_______________________________________________
>> >>Wtr-general mailing list
>> >><mailto:Wtr-general at rubyforge.org>Wtr-general at rubyforge.org
>> >>http://rubyforge.org/mailman/listinfo/wtr-general
>> >>
>> >>
>> >
>> >_____________________
>> >  Bret Pettichord
>> >  <http://www.pettichord.com>www.pettichord.com
>> >
>> >_______________________________________________
>> >Wtr-core mailing list
>> ><mailto:Wtr-core at rubyforge.org>Wtr-core at rubyforge.org
>> >http://rubyforge.org/mailman/listinfo/wtr-core
>> >
>> >
>> >
>>
>>
>>--
>>Qantom Software
>>
>><http://www.qantom.com>http://www.qantom.com
>>Ph : 91-80-26799269 Xtn. 125
>>sip : <mailto:raghu at sip411.com>raghu at sip411.com
>>--
>>
>>_______________________________________________
>>Wtr-core mailing list
>><mailto:Wtr-core at rubyforge.org>Wtr-core at rubyforge.org
>>http://rubyforge.org/mailman/listinfo/wtr-core
>
>
>
>--
>"Remember. Understand. Believe. Yield! -> 
><http://ruby-lang.org>http://ruby-lang.org"
>
>Jeff Wood

_____________________
  Bret Pettichord
  www.pettichord.com


From scott at hanselman.com  Sat Nov 12 16:52:50 2005
From: scott at hanselman.com (Scott Hanselman)
Date: Sat, 12 Nov 2005 13:52:50 -0800
Subject: [Wtr-core] Fwd: [Wtr-general] New Watir Wiki,
	was Re: FAQ  Update
In-Reply-To: <5.1.0.14.2.20051112141808.0292c768@pop.gmail.com>
Message-ID: <000f01c5e7d3$6ec028d0$0301a8c0@scottpc>

Seems totally reasonable, we host the forums for our ASP.NET application on
a PhpBB.

Scott

-----Original Message-----
From: wtr-core-bounces at rubyforge.org [mailto:wtr-core-bounces at rubyforge.org]
On Behalf Of Bret Pettichord
Sent: Saturday, November 12, 2005 12:21 PM
To: Jeff Wood; Raghu Venkataramana
Cc: wtr-core at rubyforge.org
Subject: Re: [Wtr-core] Fwd: [Wtr-general] New Watir Wiki, was Re: FAQ
Update

We have a proposal to host our wiki using better technology than we are 
currently using. (Is this in question?)

The current wiki is not Ruby-based, despite being hosted by rubyforge.org.

Unless someone else is offering to set things up on a Ruby-based wiki, i'm 
inclined to accept Sy's offer.

Bret

At 02:55 PM 11/10/2005, Jeff Wood wrote:
>... Sorry if this sounds purist, but I believe that we should be eating 
>our own dogfood here.... If it's about a ruby-based project, then put a 
>ruby-based site on top of it.
>
>I spent too many years dealing with the MUCK of PHP, I'd rather leave it 
>out of my life.
>
>j.
>
>On 11/9/05, Raghu Venkataramana 
><<mailto:raghu at qantom.com>raghu at qantom.com> wrote:
>>Bret Pettichord wrote:
>>
>> >Thoughts?
>>
>> >
>> >>Date: Tue, 08 Nov 2005 00:54:23 -0600
>> >>To: <mailto:wtr-general at rubyforge.org>wtr-general at rubyforge.org
>> >>From: Bret Pettichord <
<mailto:bret at pettichord.com>bret at pettichord.com>
>> >>Subject: [Wtr-general] New Watir Wiki, was Re:  FAQ Update
>> >>
>> >>I'm very interested in Sy's proposal (below) to host the Watir project 
>> wiki
>> >>using Media Wiki.
>> >>
>> >>I've used Wikipedia before, and i did find it to be a pretty good 
>> system. I
>> >>don't have any particular attachment to what we are using now, which is
>> >>just what rubyforge provides. I'm particular interested to know the
views
>> >>of the people who've made a lot of contibutions to our wiki.
>> >>
>> >>
>>+1.
>>I work on a project that uses a media-wiki powered wiki for its content
>>management and it sounds good.
>>
>> >>My only concern is that if we have usernames to access, it would be 
>> nice if
>> >>we could recycle the rubyforge usernames, just because that would make
it
>> >>easier for our contributors. But i'm not sure if that is really
possible.
>> >>
>> >>
>>I personally dont have any objections in recycling usernames - simply
>>because it is being done for the same
>>purpose that the user previously registered himself for. However there
>>may be others who strongly
>>oppose their details being used without consent. May be sending out an
>>invitation (just as we did for this
>>group) asking users to register to the new wiki ?
>>
>>Just my 2 cents.
>>
>>Raghu
>>
>> >>Comments?
>> >>
>> >>Bret
>> >>
>> >>At 04:45 PM 11/6/2005, Sy Ali wrote:
>> >>
>> >>
>> >>>On 11/5/05, Bret Pettichord 
>> <<mailto:bret at pettichord.com>bret at pettichord.com> wrote:
>> >>>
>> >>>
>> >>>>At 03:46 PM 11/4/2005, Sy Ali wrote:
>> >>>>
>> >>>>
>> >>>>>I'd still rather like to update the entire wiki by
>> >>>>>migrating it to mediawiki.  It was rather annoying to have had to
wade
>> >>>>>through that FAQ the few times that I did in order to clean it up
>> >>>>>somewhat (and also answer my own questions).
>> >>>>>
>> >>>>>
>> >>>>Thanks for cleaning it up. It looks a lot bettter.
>> >>>>
>> >>>>We are always open to specific proposals. Why would media wiki be 
>> better?
>> >>>>Where would it be hosted?
>> >>>>
>> >>>>
>> >>>My main issue with the existing wiki is their markup language.  The
>> >>>insistance of "CamelCase" links forces broken english titles and poor
>> >>>sentances and is an eyesore to edit.
>> >>>
>> >>>The main benefits of mediawiki would be the various different skins.
>> >>>I'm a particular fan of the default skin.  It's quite beautiful.  This
>> >>>is the first and foremost thing that everyday users would see.  The
>> >>>second would be the much nicer organization of the information.  From
>> >>>experience, I can say that it's been intuitive to organize and
>> >>>maintain a lot of information within a mediawiki installation.
>> >>>
>> >>>On the inside, the editing is very easy (the markup language is good).
>> >>> It's extremely nice to be able to edit just a section of a page.. one
>> >>>doesn't get lost on more complecated pages like a FAQ.  Automatic
>> >>>table of contents is nice.  The templating engine allows for easy
>> >>>re-use of snippets of information.  Adding inline images is trivial.
>> >>>
>> >>>For more technical reasons, mediawiki is very easy to update and
>> >>>maintain.  Updating it amounts to unpacking the new tarball over the
>> >>>previous directory and running "php update.php" (or without ssh
>> >>>access, it's still quite easy).  It's extremely easy to supervise,
>> >>>with controls for viewing recent changes and the lke.
>> >>>
>> >>>For more social reasons, MediaWiki is wildly popular and in my mind
>> >>>proved as an excellent tool because of its use for the Wikipedia.
>> >>>This is what would assure continued development.. there are a lot of
>> >>>interested people.
>> >>>
>> >>>
>> >>>My only warnings are to require usernames for editing, to use the
>> >>>spamblacklist extension and to include a one-liner regex to ban
>> >>>certain types of content.  I can provide help with these things.
>> >>>
>> >>>If hosting is an issue, I'd be pleased to host it with my resources..
>> >>>but it'll go anywhere php/mysql does.
>> >>>
>> >>>Curiously, it looks like the markup language is almost the same from
>> >>>the existing wiki to mediawiki.  This means that it would be nearly
>> >>>trivial to hand-port the content from the existing wiki to a mediawiki
>> >>>installation.  Yes, I would be willing to do this and unless you've
>> >>>got hundreds of pages of content I could get it done within two weeks.
>> >>> This would include the original wiki's content as well.
>> >>>
>> >>>My own wiki:
>> >>> http://jrandomhacker.info
>>
>>><http://jrandomhacker.info/MediaWiki>http://jrandomhacker.info/MediaWiki
>> >>>
>> >>>I also help maintain two other wikis:
>> >>>My local Linux user group (GTALUG):
>> >>><http://gtalug.org>http://gtalug.org
>> >>>
>> >>>My local Ruby user group (TRUG):
>> >>><http://trug.stok.co.uk/wiki/>http://trug.stok.co.uk/wiki/
>> >>>soon to be <http://trug.ca>http://trug.ca
>> >>>
>> >>>I've set up MediaWiki for my old work and my current business.  This
>> >>>is after a long and tiring history with a few other wikis.  MediaWiki
>> >>>has been amazing.
>> >>>
>> >>>
>> >>>In the meantime, I intend to open up a Watir-specific section in TRUG
>> >>>since I've just begun working with watir and need to begin a resource
>> >>>and code repository.  Sorry for being long-winded.. but I just got
>> >>>back from our meeting and am revved up.  =)
>> >>>
>> >>>
>> >>>Sy,
>> >>>
>> >>>_______________________________________________
>> >>>Wtr-general mailing list
>> >>><mailto:Wtr-general at rubyforge.org>Wtr-general at rubyforge.org
>> >>>http://rubyforge.org/mailman/listinfo/wtr-general
>> >>>
>> >>>
>> >>_____________________
>> >>  Bret Pettichord
>> >>  <http://www.pettichord.com>www.pettichord.com
>> >>
>> >>_______________________________________________
>> >>Wtr-general mailing list
>> >><mailto:Wtr-general at rubyforge.org>Wtr-general at rubyforge.org
>> >>http://rubyforge.org/mailman/listinfo/wtr-general
>> >>
>> >>
>> >
>> >_____________________
>> >  Bret Pettichord
>> >  <http://www.pettichord.com>www.pettichord.com
>> >
>> >_______________________________________________
>> >Wtr-core mailing list
>> ><mailto:Wtr-core at rubyforge.org>Wtr-core at rubyforge.org
>> >http://rubyforge.org/mailman/listinfo/wtr-core
>> >
>> >
>> >
>>
>>
>>--
>>Qantom Software
>>
>><http://www.qantom.com>http://www.qantom.com
>>Ph : 91-80-26799269 Xtn. 125
>>sip : <mailto:raghu at sip411.com>raghu at sip411.com
>>--
>>
>>_______________________________________________
>>Wtr-core mailing list
>><mailto:Wtr-core at rubyforge.org>Wtr-core at rubyforge.org
>>http://rubyforge.org/mailman/listinfo/wtr-core
>
>
>
>--
>"Remember. Understand. Believe. Yield! -> 
><http://ruby-lang.org>http://ruby-lang.org"
>
>Jeff Wood

_____________________
  Bret Pettichord
  www.pettichord.com

_______________________________________________
Wtr-core mailing list
Wtr-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-core



From bret at pettichord.com  Wed Nov 16 18:02:43 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 16 Nov 2005 17:02:43 -0600
Subject: [Wtr-core] [Wtr-general] New Watir Wiki
In-Reply-To: <1e55af990511152055iea1e8edrd5660dbffaa615db@mail.gmail.com
 >
References: <5.1.0.14.2.20051115120622.03c366b8@pop.gmail.com>
	<5.1.0.14.2.20051028010239.03a76340@pop.gmail.com>
	<5.1.0.14.2.20051105203413.03da8e88@pop.gmail.com>
	<5.1.0.14.2.20051108004740.03e0cf48@pop.gmail.com>
	<1e55af990511111412w5ec0cf7v67ee5fe1ff3cb07@mail.gmail.com>
	<5.1.0.14.2.20051115120622.03c366b8@pop.gmail.com>
Message-ID: <5.1.0.14.2.20051116170118.02cca308@pop.gmail.com>

I don't think we can host media wiki at rubyforge.org. We have limited 
ability to put files there, and i don't think we can get a wiki working.

If you want, you can talk to Tom et al at Rubyforge about this. I recall 
you saying something about hosting it elsewhere. Did i remember correctly?

Bret

At 10:55 PM 11/15/2005, you wrote:
>On 11/15/05, Bret Pettichord <bret at pettichord.com> wrote:
> > Please go ahead with your plan to move the Watir wiki to mediaweb. Thank
> > you very much for offering to make this contribution to the project.
>
>Good stuff.  Where do we begin?  How are things set up under sourceforge?
>
>MediaWiki is quite straightforward to install.  I recommend an
>installation in a /mw directory so as to not conflict with the
>existing directory structure.
>
>I would also recommend various config preferences be put in place
>before too long.. but that stuff can be figured out given a little bit
>of time.
>
>* Download: 
>http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.5.2.tar.gz?download
>* Installation: http://meta.wikimedia.org/wiki/Help:Installation
>* IRC: irc://irc.freenode.net/#mediawiki
>
>Installation should be as simple as:
>* Make /mw on your server
>* Download and unpack the tarball into it
>* Visit http://wtr.rubyforge.org/mw and follow the wizard
>* Copy /mw/config/LocalSettings.php to /mw/
>* Visit http://wtr.rubyforge.org/mw
>* Make a "Sy" user, and email me the password
>* Log out, then log back in as the admin and give the "Sy" user admin
>permissions
>* Give me a week for setup and basic migration, and another week for
>the legacy content.
>
>I'll be in touch regarding the spam prevension extension and a few
>trivial permissions adjustments.

_____________________
  Bret Pettichord
  www.pettichord.com


From bret at pettichord.com  Thu Nov 17 23:09:01 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Thu, 17 Nov 2005 22:09:01 -0600
Subject: [Wtr-core] [Wtr-general] New Watir Wiki
In-Reply-To: <1e55af990511171111tc0fd541ob977333ae5c49328@mail.gmail.com
 >
References: <1e55af990511171045y3c2cb7b5v3d1b08dbc74ef3cd@mail.gmail.com>
	<5.1.0.14.2.20051028010239.03a76340@pop.gmail.com>
	<5.1.0.14.2.20051105203413.03da8e88@pop.gmail.com>
	<5.1.0.14.2.20051108004740.03e0cf48@pop.gmail.com>
	<1e55af990511111412w5ec0cf7v67ee5fe1ff3cb07@mail.gmail.com>
	<5.1.0.14.2.20051115120622.03c366b8@pop.gmail.com>
	<5.1.0.14.2.20051116170118.02cca308@pop.gmail.com>
	<1e55af990511171045y3c2cb7b5v3d1b08dbc74ef3cd@mail.gmail.com>
Message-ID: <5.1.0.14.2.20051117215737.03ccf358@pop.gmail.com>

Sy,

I am cc'ing the wtr-core list. It's my new policy that i include this list 
on all "offline" discussions with project contributors. I'm also adding you 
to this list.

At 01:11 PM 11/17/2005, Sy Ali wrote:
>Ok, I can sort everything out.  It'll be easier if these things are
>all under one umbrella, so I may as well donate the resources.
>
>I've registered watir.net, and I've already set up the server.  I'll
>get the wiki set up this weekend and will begin porting the existing
>content asap.

I think that Paul owns watir.com. This could perhaps be redirected to the 
new wiki instead of wtr.rubyforge.com some day.

When you are ready to begin the content transfer, please send a note to 
wtr-general, and post a message on the wiki, telling people to hold off on 
updating the wiki until the transfer is complete.

[access information deleted]
 >the IP is 207.58.178.161 (watir.net won't work for a bit)

I'd like to see a backup administrator for the wiki, with whom you can 
share the access information. Any volunteers?

>Until the watir.net works, you can visit the site directly at
>https://korehost.net:8443/sitepreview/http/watir.net/?previous_page=dom_ctrl

Bret


_____________________
  Bret Pettichord
  www.pettichord.com


From bret at pettichord.com  Thu Nov 17 23:51:00 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Thu, 17 Nov 2005 22:51:00 -0600
Subject: [Wtr-core] Fwd: A Win32Controller for Watir
Message-ID: <5.1.0.14.2.20051117225043.03c79fe0@pop.gmail.com>

Comments?

>Subject: A Win32Controller for Watir
>Date: Wed, 16 Nov 2005 16:58:36 -0500
>From: "Petryk, Michael" <Michael.Petryk at rfsuny.org>
>To: <bret at pettichord.com>
>
>Hi Bret,
>         I used Ruby and Watir quite a bit at my last job.  I liked it 
> quite a bit.  I have followed the discussion threads quite a bit, but 
> never joined in.  So, anyway, here is a Win32Controller class that I used 
> with Watir.  I meant to flesh it out a bit more&   You may be able to use 
> it, or some of it.  I just tested some of the basic calls with Ruby ver 
> 1.8.2.0.  It still seems to work.  Great job with Watir.  I miss working 
> with it.
>
>M.
>
><<NewController.rb>>
>
>Michael Petryk
>IS QA Specialist
>
>

_____________________
  Bret Pettichord
  www.pettichord.com
-------------- next part --------------
=begin
Win32Controller.rb
class Win32Controller
	Contains methods to find and work windows, controls, etc.
	Callback functions should use the Cback module style of callback to avoid the 
	'too many callbacks' limitation.
Author: Michael Petryk
1/18/04 Intial version
=end
require 'watir'
require 'dl/import'
require 'dl/struct'
require "timeout"
require 'Win32API'

# ################################################	
#	
# 	initial version 5/25/05
#	MJP
#
#       Callbacks here don't throw 'too many callbacks' exception.
#	extern definitions are shorter.
#
#	
#
# ################################################
module Cback
  extend DL::Importable

  ENV['PATH'] += ";C:\\vt6"

  dlload "user32"
  extern "BOOL EnumWindows(void *, long)"
  extern "BOOL EnumChildWindows(long, void *, long)"
  extern "BOOL PostMessage(long, int, long, long)"
  extern "BOOL GetClassName(long, void *, int)"
  extern "BOOL GetWindowText(long, void *, int)"
  extern "int  GetWindowTextLength(long)"
  extern "BOOL IsWindowEnabled(long)"
  
  dlload "shell32"
  extern "int ShellExecute(long, void *,void *, void *,void*,int)"
  
  WM_CLOSE = 0x0010
  $aEWnd = Array.new
  $aEChildWnd = Array.new

	# Shell32.dll ShellExecute 
	def shellexec( hwnd, lpOperation, lpFile, lpParams, lpDir, nShowCmd)
		Cback.shellExecute(hwnd, lpOperation, lpFile, lpParams, lpDir, nShowCmd)
	end
	
	# Hwnd is placed on the array $aEWnd
	def enum_windows_proc(hwnd, lparam)
		#OK to push to array because it matches what ever...
		$aEWnd << hwnd 
		1
	end
	EnumWindowsProc =  callback "int enum_windows_proc(long, long)" 
	
	# Hwnd is placed on the array $aEChildWnd
	def enum_child_windows_proc(hwnd, lparam)
		$aEChildWnd << hwnd
		1
	end
	EnumChildWindowsProc = callback "int enum_child_windows_proc(long, long)"

	# * hwnd	= Handle to a window (long).
	# * winclass	= String representing the class. Ex. '#32770'
	# Returns true if <b>hwnd</b> is of <b>winclass</b>
	def iswinclass?(hwnd, winclass)
		buff = DL.malloc(16)
		r = Cback.getClassName(hwnd, buff, buff.size)
		if /^#{winclass}$/ =~ buff.to_s
			return true
		end
		return false
	end
	
	# * hwnd	= Handle to a window (long).
	# * title	= Title or text of the window (string)
	# Returns true if <b>hwnd</b> is of <b>winclass</b>
	def iswintext?(hwnd, title)
		len = Cback.getWindowTextLength(hwnd) + 1
		buff = DL.malloc(len)
		r = Cback.getWindowText( hwnd, buff, buff.size)
		if /^#{title}$/ =~ buff.to_s
			return true
		end
		return false
	end
end #Cback module


# ################################################	
#
#	Contains methods to find and work windows, controls, etc.
#	Callback functions should use the Cback module style of callback to avoid the 
#	'too many callbacks' limitaion.
#
# 	initial version 9/21/04
#       2/11/05 Watir update
#	MJP
# ################################################
class Win32Controller
	include Cback	

    WM_CLOSE    		= 0x0010
    WM_KEYDOWN  	= 0x0100
    WM_KEYUP    		= 0x0101
    WM_CHAR     		= 0x0102
    WM_COMMAND  	= 0x0111
    WM_SETTEXT  	= 0x000C
    WM_GETTEXT  	= 0x000D

    HWND_TOP 		= 0
    HWND_BOTTOM 	= 1
    HWND_TOPMOST 	= -1
    HWND_NOTOPMOST = -2

    SWP_SHOWWINDOW = 0x40
    SWP_NOSIZE  	= 1
    SWP_NOMOVE 	= 2

    SW_MINIMIZE 	= 6
    SW_SHOW      	= 5 # activate
    SW_RESTORE  	= 9
    
    BM_CLICK    		= 0x00F5

    TRUE_1 = 1

    # these are constants for commonly used windows
    WINCLASS_DIALOG 	= "#32770"
    WINCLASS_MENU	= "#32768"

	# Set current path.
	# Append 'c:\\vt6' to env path.
	# Call Win32Functions.
	def initialize()
		@path_to_Win32Controller = File.expand_path(File.dirname(__FILE__))
		ENV['PATH']
		Win32Functions()
	end
	
	# Common Win32 functions are initialized.
	def Win32Functions()
		@User32 		= DL.dlopen('user32')
		@FindWindow 	= Win32API.new('user32','FindWindow',['p','p'], 'L')
		#@FindWindow2 	= @User32['FindWindow', 'PPP']
		@post_message 	= @User32['PostMessage', 'ILILL']
		@sendMessage 	= Win32API.new('user32', 'SendMessage',  ['L','L','L','P'], 'L') 
		@IsWindow		= @User32['IsWindow', 'IL']
		

	end

	# Used to call EnumWindows.
	# Usage: <b>r,aHwnd = enumerateWindows( text, wclass) { |h| ... }</b>
	#
	# * text -Title or text of window to find (string). <i>Default = ''</i>
	# * wclass -Class of window to find (string). <i>Default = '0'</i>
	# * You must pass a block, { }, for enumerateWindows to <i>yield</i> to. This may be empty.
	# Returns true, and array of Hwnd found if successful.
	def enumerateWindows( text = '', wclass = '0')
		$aEWnd.clear
		Cback.enumWindows(EnumWindowsProc, 0 )		
		r = false
		aWinClass = Array.new
		$aEWnd.each {|h|
			#compare class if available
			if wclass == '0'
				aWinClass << h
			else
				if iswinclass?(h, wclass)
					aWinClass << h
				end
			end
		}
		$aEWnd.clear
		#compare title/text if available
		if text.to_s.length > 0
			aWinClass.delete_if {|h| iswintext?(h, text) == false}
		end
		aWinClass.each {|h|
			yield(h)
			r = true
		}
		return r, aWinClass
	end

	# Used to call EnumChildWindows.
	# Usage: <b>r,aHwnd = enumerateWindows( text, wclass) { |h| ... }</b>
	#
	# * parent -Hwnd of the parent window (long).
	# * text -Title or text of window to find (string). <i>Default = ''</i>
	# * wclass -Class of window to find (string). <i>Default = '0'</i>
	# * You must pass a block, { }, for enumerateWindows to <i>yield</i> to. This may be empty.
	# Returns true, and array of Hwnd found if successful.
	def enumerateChildWindows( parent = 0, text = '', wclass = '0')
		$aEChildWnd.clear
		Cback.enumChildWindows(parent, EnumChildWindowsProc, 0 )

		r = false
		aWinClass = Array.new
		$aEChildWnd.each {|h|
			#compare class if available
			if wclass == '0'
				aWinClass << h
			else
				if iswinclass?(h, wclass)
					aWinClass << h
				end
			end
		}
		$aEChildWnd.clear
		#compare title/text if available
		if text.to_s.length > 0
			aWinClass.delete_if {|h| iswintext?(h, text) == false}
		end
		aWinClass.each {|h|
			yield(h)
			r = true
		}
		return r, aWinClass
	end


	# Uses Win32 FindWindow to look for a top level window.
	# * title -String of window text.
	# * winclass -String of window class
	# * wait -Integer value for number of seconds to search. 
	def FindWindowWait( title, winclass= "", wait =5 )
		begin 
		hwnd = @FindWindow.call(winclass, title)
		count = 0
		while hwnd < 1 and wait > count
			sleep 0.5
			count += 0.5
			hwnd = @FindWindow.call(winclass, title)
		end
		rescue
			puts 'FindWindowWait err'
		end
		return hwnd
	end

	# Executes a crtdll system call and waits.
	# * command -String containing the command.
	def winsystem(command)
	      # http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt_system.2c_._wsystem.asp
	      # using win32api
	      pid  =  Win32API.new("crtdll", "system", ['P'], 'L').Call(command)
	
	      # using DL
	      #winapi= DL.dlopen("crtdll")
	      #sys = winapi['system' , '??']
	end
	
	# * h -Hwnd of window.
	# Returns true if h is visible.
	def isWindowVisible?( h )
		isWindowVisible= Win32API.new("user32","IsWindowVisible", ["L"] ,'L')
		r = isWindowVisible.call( h.to_i)
	end
	
	# * hwnd -Hwnd of window.
	# Returns length of text string as an integer.
	def GetWindowTextLength( hwnd )
		get_window_text_length = @User32['GetWindowTextLength', 'IL']
		r,rs	= get_window_text_length.call( hwnd.to_i)
		return r.to_i + 1
	end
	
	# * hwnd -Hwnd of window.
	# Returns the text string or title of a window.
	def GetWindowText(hwnd)
		get_window_text = @User32['GetWindowText', 'ILpI']
		buff = " " * GetWindowTextLength( hwnd )
		r,rs  = get_window_text.call(hwnd.to_i, buff, buff.size)
		return rs[1].to_s
	end
	
	# * hwnd -Valid window handle.
	def RestoreWindow( hwnd )
		ShowWindow( hwnd, SW_RESTORE)
	end

	# * hwnd -Valid window handle.
	def MinimizeWindow( hwnd )
		ShowWindow( hwnd, SW_MINIMIZE)
	end
	
	# * hwnd -Valid window handle.
	# * flags -See MSDN docs.
	def ShowWindow( hwnd, flags )
		showWindow = @User32['ShowWindow', 'ILI']
		r,rs	= showWindow.call( hwnd.to_i, flags )
		return r.to_i
	end

	# * hwnd -Valid window handle.
	# Set it to be the one with focus
	def makeWindowActive (hWnd)
		switch_to_window = @User32['SwitchToThisWindow' , 'pLI'  ]
		ShowWindow( hWnd, SW_SHOW)
		sleep 0.01
		switch_to_window.call(hWnd , 1)
	end

	# * hwnd -Valid window handle.
	def closeWindow( hwnd )
		r, rs = @post_message.call(hwnd.to_i, WM_CLOSE, 0, 0)
		return r
	end

	#Returns string with computerName.
	def GetComputerName()
		@getcomputername= Win32API.new('kernel32','GetComputerNameA', ['P','P'] ,'L')

		buff = "\0" * 255
		size = [255].pack('L')
		r,rs = @getcomputername.call(buff,size)
		return buff.gsub(/\000/,'')
		#  This is how to unpack the size. It's better to just trim the chars here.
		#p size.unpack('L')[0]
		#p buff[0..size.unpack('L')[0]-1]  <- So I didn't do it.
	end

	# Closes all IE windows.
	def CloseIE()		
		while (h = @FindWindow.call('IEFrame', 0))>0  
			closeWindow( h ) 
			sleep 0.1
		end
	end
	
	# Restores one IE window.
	def RestoreIE()		
		#while (h = @FindWindow.call('IEFrame', 0))>0  
		if (h = @FindWindow.call('IEFrame', 0))>0  
			RestoreWindow( h ) 
			sleep 0.1
		end
	end


	# buttonhWnd -long
	# Posts a BM_CLICK message to this Hwnd.
	def clickButtonWithHandle(buttonhWnd)
		 post_message = @User32['PostMessage', 'ILILL']
		 r = post_message.call(buttonhWnd, BM_CLICK, 0, 0)
	end

	# Returns parents Hwnd if successful.
	def getParent (childhWnd )
		# pass a hWnd into this function and it will return the parent hWnd
		getParentWindow = @User32['GetParent' , 'II' ]
	
		puts " Finding Parent for: " + childhWnd.to_s
		a , b = getParentWindow.call(childhWnd )
		#puts "a = " a.to_s , b.to_s
		return a
	end

=begin    
    def getStaticText(caption)
        return getStaticTextFromWindow(caption, -1)
    end

    def getStaticText_hWnd (hWnd)
        return getStaticTextFromWindow("" , hWnd)
    end
=end
 
        # Returns the title for the specified hwnd
	def getWindowTitle(hWnd )
		 buff = " " * 256
		getWindowText = User32['GetWindowText' , 'ILSI']
		r , rs = getWindowText.call( hWnd , buff , 256 )
		puts 'send message returned: ' + r.to_s + ' text is: ' + buff.to_s
		return buff.to_s
	end


	# * hWnd -Valid ComboBox handle.
	# * textToSet -String.
	def setComboBoxText(hWnd , textToSet)
		send_message = @User32['SendMessage',  'ILISS']  
		r  ,rs  = send_message.call(hWnd , WM_SETTEXT , '' ,  textToSet   )
		puts 'send message returned: ' + r.to_s 
	end

	# * hWnd -Valid Window handle.
	# * string -Title or text to set.
	def SetWindowText(hWnd, string)
		setWindowText = @User32['SetWindowText' , 'ILS']
		r, rs = setWindowText.call(hWnd, string.to_s)
		return r
	end

	# Checks for windows taskbar to see if a 98 PC is not logged onto the LAN.
	# Then looks for loggin dialog and enters userInfo to log PC onto the LAN.
	# * userInfo -Array of [userId, pwd, domain] 
	def checkWindowsLogin(userInfo) 
		hwndTaskbar = FindWindowWait('','Shell_TrayWnd', 1) # If you have this you are logged in.
		if hwndTaskbar < 1
			p 'check windowslogin true'
			r, rs = enumerateWindows('Enter Network Password'){|hwnd|
				makeWindowActive(hwnd)
				cr, crs = enumerateChildWindows(hwnd,'','Edit'){}
				3.times{|i| @sendMessage.call(crs[i], 0x000C,-1, userInfo[i].to_s) if crs[i] }
				sleep 1
				
				r, rs = enumerateChildWindows(hwnd, 'OK', 'Button') {|b|
					clickButtonWithHandle(b) if Cback.isWindowEnabled(b) 
				sleep 10
				}
			}
		end
	end


	# Finds a window and clicks a button on it.
	# * title -Of the dialog, window, or child window (string).
	# * button -Label on button (string).
	def WinActions(title, button)
		b = -1
		if (hwnd = @FindWindow.call('#32770', title)) < 1
		    if (hwnd = @FindWindow.call('', title)) < 1
			  r, rs = enumerateWindows( title ){|h| hwnd = h }
		    end
		end
		if hwnd > 0
			makeWindowActive(hwnd)
			r, rs = enumerateChildWindows(hwnd, button, 'Button') {|b|
				clickButtonWithHandle(b) if Cback.isWindowEnabled(b) 
			}
			b = rs[0]
		end
	end

end #Win32Controller
=begin
To test open Notepad.
Click "Help".
Click "About Notepad"
=end
c = Win32Controller.new
p c.GetComputerName()
c.WinActions( "About Notepad", "OK")

From sy1234 at gmail.com  Fri Nov 18 11:10:46 2005
From: sy1234 at gmail.com (Sy Ali)
Date: Fri, 18 Nov 2005 10:10:46 -0600
Subject: [Wtr-core] [Wtr-general] New Watir Wiki
In-Reply-To: <5.1.0.14.2.20051117215737.03ccf358@pop.gmail.com>
References: <5.1.0.14.2.20051028010239.03a76340@pop.gmail.com>
	<5.1.0.14.2.20051105203413.03da8e88@pop.gmail.com>
	<5.1.0.14.2.20051108004740.03e0cf48@pop.gmail.com>
	<1e55af990511111412w5ec0cf7v67ee5fe1ff3cb07@mail.gmail.com>
	<5.1.0.14.2.20051115120622.03c366b8@pop.gmail.com>
	<5.1.0.14.2.20051116170118.02cca308@pop.gmail.com>
	<1e55af990511171045y3c2cb7b5v3d1b08dbc74ef3cd@mail.gmail.com>
	<5.1.0.14.2.20051117215737.03ccf358@pop.gmail.com>
Message-ID: <1e55af990511180810u7ed18096pfbf847ca1def58ab@mail.gmail.com>

On 11/17/05, Bret Pettichord <bret at pettichord.com> wrote:
> I am cc'ing the wtr-core list. It's my new policy that i include this list
> on all "offline" discussions with project contributors. I'm also adding you
> to this list.

Good stuff.  =)


> I think that Paul owns watir.com. This could perhaps be redirected to the
> new wiki instead of wtr.rubyforge.com some day.

Aah, I wondered why all the cool watir.* addresses had been snatched up.


> When you are ready to begin the content transfer, please send a note to
> wtr-general, and post a message on the wiki, telling people to hold off on
> updating the wiki until the transfer is complete.

Will-do.  I'm finally getting some personal system issues sorted out,
so things are on-target.  A faster computer means faster wiki-ing.  ;)


From chrismo at clabs.org  Fri Nov 18 15:35:25 2005
From: chrismo at clabs.org (Chris Morris)
Date: Fri, 18 Nov 2005 14:35:25 -0600
Subject: [Wtr-core] Fwd: A Win32Controller for Watir
In-Reply-To: <5.1.0.14.2.20051117225043.03c79fe0@pop.gmail.com>
References: <5.1.0.14.2.20051117225043.03c79fe0@pop.gmail.com>
Message-ID: <437E3B0D.1030703@clabs.org>

Bret Pettichord wrote:

> Comments?

Assuming good coverage of Win32API stuffs - or even if not - I think 
it's very cool. I dunno how much at the Watir level would abstract to 
both underlying concepts. I'd be interested in trying to use it.

-- 
Chris
http://clabs.org/blogki


From christopher.mcmahon at gmail.com  Fri Nov 18 16:29:16 2005
From: christopher.mcmahon at gmail.com (Chris McMahon)
Date: Fri, 18 Nov 2005 15:29:16 -0600
Subject: [Wtr-core] Fwd: A Win32Controller for Watir
In-Reply-To: <5.1.0.14.2.20051117225043.03c79fe0@pop.gmail.com>
References: <5.1.0.14.2.20051117225043.03c79fe0@pop.gmail.com>
Message-ID: <72799cd70511181329l86386acw547123cd1399daa@mail.gmail.com>

On 11/17/05, Bret Pettichord <bret at pettichord.com> wrote:
> Comments?

Looks reasonable to me.  Seems to be some useful methods missing--
"FindWindowLike" was my bread and butter when I was doing this.

I'm Ccing Wayne on this because he's been working along similar lines.
-Chriss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NewController.rb
Type: text/x-ruby-script
Size: 12634 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/wtr-core/attachments/20051118/8bd9bc23/NewController.bin

From raghu at qantom.com  Sun Nov 20 23:31:57 2005
From: raghu at qantom.com (Raghu Venkataramana)
Date: Mon, 21 Nov 2005 10:01:57 +0530
Subject: [Wtr-core] [Fwd: [Wtr-general] support request]
Message-ID: <43814DBD.7060508@qantom.com>

If it is still outstanding and we need such a feature, let me know. I have
support for such a feature in WET and I can add it to Watir.

Thanks
Raghu

-------- Original Message --------
Subject: 	[Wtr-general] support request
Date: 	Sun, 20 Nov 2005 17:45:13 -0600
From: 	Bret Pettichord <bret at pettichord.com>
Reply-To: 	wtr-general at rubyforge.org
To: 	wtr-general at rubyforge.org



Here is a support request form a month ago:

Richard Green, beforeText and afterText
http://rubyforge.org/tracker/?atid=488&group_id=104&func=browse

Is this still outstanding?

Bret

_____________________
  Bret Pettichord
  www.pettichord.com

_______________________________________________
Wtr-general mailing list
Wtr-general at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general



-- 
Qantom Software

http://www.qantom.com
Ph : 91-80-26799269 Xtn. 125
sip : raghu at sip411.com
--


From bret at pettichord.com  Mon Nov 21 10:40:28 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 21 Nov 2005 09:40:28 -0600
Subject: [Wtr-core] Scripting Class
Message-ID: <5.1.0.14.2.20051121093437.03e38138@pop.gmail.com>

I have declined SQE's request that i teach the Scripting101 Watir Tutorial 
at Star East in Orlando in May. They have asked me to see if i can find 
someone else.

I've been teaching the class with the following arrangement.
- $1,500 for a lead and assistant instructor
- Reimbursement for airfare and two nights hotel
- Free pass to the STAR conference
- Class size limited to 24.

You of course may want to negotiate a different arrangement. All of the 
class materials are part of the WTR project.

If any of you are interested, you may contact me or Lee Copeland 
<lcopeland at sqe.com>.

Bret


_____________________
  Bret Pettichord
  www.pettichord.com


From jeff.darklight at gmail.com  Mon Nov 21 11:27:51 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Mon, 21 Nov 2005 08:27:51 -0800
Subject: [Wtr-core] show_tables, etc.
Message-ID: <b539c61e0511210827kf9be12ej9bd3eb345fb1c078@mail.gmail.com>

Ok, so, looking @ HEAD I see that there's already a nice replacement
framework in place inside ElementCollection to do show functionality.

So, why not get rid of the show_tables, etc functionality ( or at least just
have it wrap the new functionality ) ???

I mean we now have

ie.show_tables

and

ie.tables.show

... I think they should both simply map to ie.tables.show

And, I'd really like to see tables accept a block as input to let you use
more ruby-based syntax for selecting tables to include.

ie.tables { |t| t.html =~ /blah/ } ## would return a subset of the total
table collection ...

## and mixing in #show

ie.tables { |t| t.html =~ /blah/ }.show ## would do the #show function, but
would only show the objects that had resulted in a true from the block.


Anyways, that's just my thoughts.

j.

--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051121/e9312139/attachment-0001.htm

From christopher.mcmahon at gmail.com  Mon Nov 21 11:36:33 2005
From: christopher.mcmahon at gmail.com (Chris McMahon)
Date: Mon, 21 Nov 2005 10:36:33 -0600
Subject: [Wtr-core] Scripting Class
In-Reply-To: <5.1.0.14.2.20051121093437.03e38138@pop.gmail.com>
References: <5.1.0.14.2.20051121093437.03e38138@pop.gmail.com>
Message-ID: <72799cd70511210836wd255742pdb1d1a6c46c0fc0@mail.gmail.com>

I enjoyed being the assistant.  I would teach this class again.
-Chris

On 11/21/05, Bret Pettichord <bret at pettichord.com> wrote:
> I have declined SQE's request that i teach the Scripting101 Watir Tutorial
> at Star East in Orlando in May. They have asked me to see if i can find
> someone else.
>
> I've been teaching the class with the following arrangement.
> - $1,500 for a lead and assistant instructor
> - Reimbursement for airfare and two nights hotel
> - Free pass to the STAR conference
> - Class size limited to 24.
>
> You of course may want to negotiate a different arrangement. All of the
> class materials are part of the WTR project.
>
> If any of you are interested, you may contact me or Lee Copeland
> <lcopeland at sqe.com>.
>
> Bret
>
>
> _____________________
>   Bret Pettichord
>   www.pettichord.com
>
> _______________________________________________
> Wtr-core mailing list
> Wtr-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-core
>


From bret at pettichord.com  Mon Nov 21 13:33:01 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 21 Nov 2005 12:33:01 -0600
Subject: [Wtr-core] show_tables, etc.
In-Reply-To: <b539c61e0511210827kf9be12ej9bd3eb345fb1c078@mail.gmail.com
 >
Message-ID: <5.1.0.14.2.20051121121725.03c72fc8@pop.gmail.com>

At 10:27 AM 11/21/2005, Jeff Wood wrote:
>Ok, so, looking @ HEAD I see that there's already a nice replacement 
>framework in place inside ElementCollection to do show functionality.
>
>So, why not get rid of the show_tables, etc functionality ( or at least 
>just have it wrap the new functionality ) ???

That's the plan.

>I mean we now have
>
>ie.show_tables
>
>and
>
>ie.tables.show

The plan is to deprecate show_tables in favor of tables.show.

But, there are a places where we don't have x.show methods to replace 
current *_show methods. The most glaring is show_all_objects which should 
be replaced by elements.show. I think we are also missing x.show for frames 
and maybe forms. This is also complicated by the fact that i think we do 
have a form().elements at present.

I'd like to see this cleaned up and completed for 1.5, so we can start 
telling people to use the x.show methods instead, which i agree are cleaner.

>... I think they should both simply map to ie.tables.show
>
>And, I'd really like to see tables accept a block as input to let you use 
>more ruby-based syntax for selecting tables to include.
>
>ie.tables { |t| t.html =~ /blah/ }  ## would return a subset of the total 
>table collection ...

Something very close to this is already possible:

   ie.tables.select { |t| t.outerhtml =~ /blah/ }

However, this currently binds t to the COM object, not the Watir table 
object. So for example, that means you have to use COM's outerhtml method 
rather than than Watir's html method. It also returns a collection of COM 
objects, rather than Watir objects.

Paul and i agree this should change, but it's not scheduled for 1.5 and is 
potentially very disruptive.

>## and mixing in #show
>
>ie.tables { |t| t.html =~ /blah/ }.show  ## would do the #show function, 
>but would only show the objects that had resulted in a true from the block.

Bret

_____________________
  Bret Pettichord
  www.pettichord.com


From paul.rogers at shaw.ca  Mon Nov 21 22:13:13 2005
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Mon, 21 Nov 2005 20:13:13 -0700
Subject: [Wtr-core] [Wtr-general] Mozilla support
In-Reply-To: <20051118113452.17439.qmail@web34815.mail.mud.yahoo.com>
Message-ID: <004601c5ef12$aca484c0$6600a8c0@NewDell>



Ive also tried jssh, not recently though. This may be an easy way to get
moz support into watir. The author of the tool was helpful when I had
questions. 

Paul


-----Original Message-----
From: cp [mailto:cp_jain at yahoo.com] 
Sent: 18 November 2005 04:35
To: paul.rogers at shaw.ca
Cc: cp_jain at yahoo.com
Subject: [Wtr-general] Mozilla support


Hi Paul,

This is in response to your posting in Watir mailing
list.

I tried jssh with mozilla v1.8b and it worked. You can
download
this version from here -
http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.8b1/

After instllation, load "jssh-20050308-Linux.xpi" with
File->Open File.

Let me know if you have any issue.

Chandraprakash Jain



		
__________________________________________________________ 
Enjoy this Diwali with Y! India Click here
http://in.promos.yahoo.com/fabmall/index.html


From bret at pettichord.com  Tue Nov 22 21:57:23 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 22 Nov 2005 20:57:23 -0600
Subject: [Wtr-core] Fwd: Re: New implementation of XPath support without tidy
Message-ID: <5.1.0.14.2.20051122205405.02e52410@pop.gmail.com>

Please comment on this issue.

Currently, the xpath support in Watir depends on an on unreleased version 
of REXML. The fix is in HEAD, but unreleased.

The modal dialog support i will commit real soon now also depends on 
patching WIN32OLE. This fix has not even yet been submitted (I have a 
private copy, though). I actually could use some help with this. My initial 
email to the WIN32OLE went unanswered. Anyone here know Japanese?

Bret:
>>I'm starting to plan the rollout of 1.5. I'm not sure how we are going to
>>handle the install. Properly, a gem can't modify a separate library. Our
>>one-click installer can, but we'll create problems if the users don't have
>>the right version of REXML already installed. Maybe we should have a
>>separate script to install these files? What are your and Abhishek's 
>>thoughts?

Angrez:
>We think that it would not be easy to distribute the correct REXML 
>version. We can perhaps notify the user to get the latest versions these 
>files from the CVS of REXML because they are fixed but not released. And 
>also they will be releasing the correct version soon.
>or
>We can have patch for those two files and we can ask the user to manually 
>patch these files if they are not having the correct version of REXML.
>what do you think?

_____________________
  Bret Pettichord
  www.pettichord.com


From bret at pettichord.com  Tue Nov 22 23:01:51 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 22 Nov 2005 22:01:51 -0600
Subject: [Wtr-core] Fwd: Re: New implementation of XPath support without
 tidy
In-Reply-To: <002301c5efe0$9826a770$6500a8c0@tintin>
References: <5.1.0.14.2.20051122205405.02e52410@pop.gmail.com>
Message-ID: <5.1.0.14.2.20051122215332.02ecc008@pop.gmail.com>

At 09:47 PM 11/22/2005, Jonathan Kohl wrote:
> > Currently, the xpath support in Watir depends on an on
> > unreleased version of REXML. The fix is in HEAD, but unreleased.
>Sounds like we should release this after the REXML release goes out to make
>things smooth for users.

I think this is right for full-fledged official support of XPATH.

However, if we release Watir 1.5 before the next release of REXML (which i 
think may be likely), then i would want to say that our support for XPATH 
in this release would be beta, with instructions or a special install 
script that would make it work.

Another issue: So far, watir has not had any dependencies on anything other 
than Ruby itself, although we had to warn against using some versions of 
Ruby because of bad WIN32OLE libraries. Also, the IEController itself had a 
dependency on WIN32OLE back when that was not included in the standard Ruby 
installation.

Anyhow, i am very reluctant to add dependencies to Watir now -- from a 
user's perspective. I'm happy to use the gem system to manage dependencies 
for the watir gem. But i would like the Watir-one-click installer to be a 
single download that can be installed off line. That may mean bundling 
dependent gems in the install package.

Thoughts?

BTW, i am leaning towards making the next release 1.5.0 and marking it as 
"beta". The other option would be to call it 1.5 preview. The biggest issue 
with this is how to handle the gem. The ruby-talk list recommended that we 
set up a separate beta server to host the beta gem. But still it would need 
to have a number. The advantage to this is that "gem install ruby" wouldn't 
get the "beta" version unless you explicitly pointed it at the beta-gem-server.

Bret


_____________________
  Bret Pettichord
  www.pettichord.com


From bret at pettichord.com  Wed Nov 23 16:30:32 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 23 Nov 2005 15:30:32 -0600
Subject: [Wtr-core] Please talk amongst yourselves
Message-ID: <5.1.0.14.2.20051123152738.037b0fd8@pop.gmail.com>

Many of you are sending me private replies to queries i'm making about work 
from other contributors. This doesn't really help me. If you have 
suggestions, you need to make them to the other contributors. Or to this 
list, which is why i created it.

I'm trying to develop a consensus process, which is impossible if all the 
discussion is offline.

Bret


_____________________
  Bret Pettichord
  www.pettichord.com


From jkohl at telusplanet.net  Wed Nov 23 16:42:50 2005
From: jkohl at telusplanet.net (jkohl@telusplanet.net)
Date: Wed, 23 Nov 2005 13:42:50 -0800
Subject: [Wtr-core] Please talk amongst yourselves
In-Reply-To: <5.1.0.14.2.20051123152738.037b0fd8@pop.gmail.com>
References: <5.1.0.14.2.20051123152738.037b0fd8@pop.gmail.com>
Message-ID: <1132782170.4384e25ae1ac2@webmail.telus.net>



> Many of you are sending me private replies to queries i'm making about work 
> from other contributors. This doesn't really help me. If you have 
> suggestions, you need to make them to the other contributors. Or to this 
> list, which is why i created it.
> 
> I'm trying to develop a consensus process, which is impossible if all the 
> discussion is offline.
This happened to me because "reply" went to you; not the wtr-core mailing list
so I didn't realize this was happening.

-Jonathan


From christopher.mcmahon at gmail.com  Wed Nov 23 16:45:43 2005
From: christopher.mcmahon at gmail.com (Chris McMahon)
Date: Wed, 23 Nov 2005 15:45:43 -0600
Subject: [Wtr-core] Please talk amongst yourselves
In-Reply-To: <72799cd70511231345y34841cc1rb34685a909b0c355@mail.gmail.com>
References: <5.1.0.14.2.20051123152738.037b0fd8@pop.gmail.com>
	<72799cd70511231345y34841cc1rb34685a909b0c355@mail.gmail.com>
Message-ID: <72799cd70511231345n1a78b9b3mf97671535b6f44fd@mail.gmail.com>

> I'm trying to develop a consensus process, which is impossible if all the
> discussion is offline.

About the time I started working with Watir, I was also working with
PXELINUX (http://syslinux.zytor.com/pxe.php) Anvin, the guy who
maintains PXELINUX, would always forward your private message (along
with the verbal spanking he gave you) to the whole mail list.  It was
an effective tactic.
-Chris


From dave at burt.id.au  Wed Nov 23 17:45:10 2005
From: dave at burt.id.au (Dave Burt)
Date: Thu, 24 Nov 2005 09:45:10 +1100
Subject: [Wtr-core] Fwd: Fwd: Re: New implementation of XPath support
	without tidy
In-Reply-To: <3ad74bc80511222012i6066b176i19039c66028d961f@mail.gmail.com>
References: <5.1.0.14.2.20051122205405.02e52410@pop.gmail.com>
	<3ad74bc80511222012i6066b176i19039c66028d961f@mail.gmail.com>
Message-ID: <3ad74bc80511231445j26edf36n1cb6d3a69461b597@mail.gmail.com>

> Please comment on this issue.
>
> Currently, the xpath support in Watir depends on an on unreleased version
> of REXML. The fix is in HEAD, but unreleased.

If the patch or relevant bits of it can be included in a stand-alone
file, one option would be to include it like this:

require 'rexml/xpath'  # existing code in Watir
if REXML.Version <= "3.1.3"  # add this
  # Re-open the class and replace/add methods that need
  # replacing/adding.
  require 'watir/futurefiles/rexml/xpath'
end

> The modal dialog support i will commit real soon now also depends on
> patching WIN32OLE. This fix has not even yet been submitted (I have a
> private copy, though). I actually could use some help with this. My initial
> email to the WIN32OLE went unanswered. Anyone here know Japanese?

Have you tried posting to ruby-core?

(Sorry for mis-addressing it before, Bret.)

Cheers,
Dave


From bret at pettichord.com  Fri Nov 25 13:14:11 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Fri, 25 Nov 2005 12:14:11 -0600
Subject: [Wtr-core] Please talk amongst yourselves
In-Reply-To: <1132782170.4384e25ae1ac2@webmail.telus.net>
References: <5.1.0.14.2.20051123152738.037b0fd8@pop.gmail.com>
	<5.1.0.14.2.20051123152738.037b0fd8@pop.gmail.com>
Message-ID: <5.1.0.14.2.20051125121248.03801de0@pop.gmail.com>

At 03:42 PM 11/23/2005, jkohl at telusplanet.net wrote:
>This happened to me because "reply" went to you; not the wtr-core mailing list
>so I didn't realize this was happening.

I reconfigured the list to resend replies to the list.

Bret


_____________________
  Bret Pettichord
  www.pettichord.com


From jeff.darklight at gmail.com  Fri Nov 25 13:37:52 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Fri, 25 Nov 2005 10:37:52 -0800
Subject: [Wtr-core] Please talk amongst yourselves
In-Reply-To: <5.1.0.14.2.20051125121248.03801de0@pop.gmail.com>
References: <5.1.0.14.2.20051123152738.037b0fd8@pop.gmail.com>
	<1132782170.4384e25ae1ac2@webmail.telus.net>
	<5.1.0.14.2.20051125121248.03801de0@pop.gmail.com>
Message-ID: <b539c61e0511251037y4de24a90rb93de279b2697229@mail.gmail.com>

Yep, and it appears to work ;)

j.

On 11/25/05, Bret Pettichord <bret at pettichord.com> wrote:
>
> At 03:42 PM 11/23/2005, jkohl at telusplanet.net wrote:
> >This happened to me because "reply" went to you; not the wtr-core mailing
> list
> >so I didn't realize this was happening.
>
> I reconfigured the list to resend replies to the list.
>
> Bret
>
>
> _____________________
>   Bret Pettichord
>   www.pettichord.com
>
> _______________________________________________
> Wtr-core mailing list
> Wtr-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-core
>



--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051125/a35cf489/attachment-0001.htm

From waynev at gmail.com  Sun Nov 27 02:51:57 2005
From: waynev at gmail.com (Wayne Vucenic)
Date: Sat, 26 Nov 2005 23:51:57 -0800
Subject: [Wtr-core] Ruby Win32::GuiTest Current Status
Message-ID: <88c9ce410511262351g34cb2176tc7289f97820afd4b@mail.gmail.com>

As some of you know, I've been working on the Ruby Win32::GuiTest library,
inspired by Perl's Win32::GuiTest.  This project was started a few
years ago by Moonwolf, but had been dormant for quite a while.

Recently, I've been focusing on changing the Perlish/VBish interface
to something more Rubylike, as I like to focus on first getting a
good interface, then working on the implementation.

In the process, I threw away all my earlier sendkeys code and redesigned it to
support a simpler way of specifying the keys to be sent.  What used to
be:

  sendkeys("2{+}2~")

is now

  sendkeys("2+2\r")

Keys which were represented by names were sent like

  sendkeys("{ESCAPE}")

now it's

  sendkeys(key("ESCAPE"))

The shift, ctrl, and alt keys were represented by obscure codes: +, ^,
and %.  So sending ctrl-A was

   sendkeys("^A")

now it's

   sendkeys(ctrl("A"))

Similarly for shift("xyz") and alt("xyz").  These can, of course, be nested

  sendkeys(ctrl(alt(key('DELETE')))

Parameters which are not strings have "to_s" called on them, so

  sendkeys(123)

is the same as

  sendkeys("123")

sendkeys takes any number of arguments:

  sendkeys(iMin, '+', 47, ctrl('C'))

I made similar changes to the rest of the code:

Finding a top level window whose title contained 'foo" was:

  findWindowLike(0, /foo/)

where, among other things, one had to know that the windows we're interested
in have 0 as the parent window, and that this method takes a 2nd parameter
which is the pattern to match the window title.

Now it's:

  ToplevelWindows.find {|w| w.title =~ /foo/}

which I think is more readable and Rubylike.  This also allows more
complex expressions:

  ToplevelWindows.find {|w| (w.title =~ /foo/ and w.title != 'foobar') or
                                   w.windowId == 123}

The test cases are good examples of how to call the various methods.
In particular guitest_tc.rb does some simple testing on the Calculator
accessory:


class TC_GuiTest < Test::Unit::TestCase
  def test_1
    unless ToplevelWindows.find {|w| w.title == 'Calculator'}
        createProcess(nil, 'calc')
    end
    wCalc = ToplevelWindows.find {|w| w.title == 'Calculator'}

    wCalc.sendkeys("2+2\r")

    wEdit = wCalc.children.find {|w| w.classname == 'Edit'}
    assert_equal('4.', wEdit.windowText)

    assert_equal(wCalc, wEdit.parent)

    assert(wCalc.rect.top <= wEdit.rect.top && wCalc.rect.bottom >=
              wEdit.rect.bottom &&
              wCalc.rect.left <= wEdit.rect.left && wCalc.rect.right
>= wEdit.rect.right)

    a = 123
    b = 456
    wCalc.sendkeys(a, "+", b, "\r")
    assert_equal((a+b).to_s+'.', wEdit.windowText)

    wCalc.close
  end
end

I'm fairly happy with the API, except that I don't like the duplication in:

   unless ToplevelWindows.find {|w| w.title == 'Calculator'}
       createProcess(nil, 'calc')
   end
   wCalc = ToplevelWindows.find {|w| w.title == 'Calculator'}

but I have some ideas on how to remove this duplication.

I've attached all the files you need to run this.  I also regularly
check the code into the RubyForge project ("guitest") that
Chris McMahon and I have (but the attached files are newer than
what's presently checked in.)

The code is still definitely a work in progress.  Every time I work
with it I find a number of things that I clean up or refactor.

Wayne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: guitest.zip
Type: application/zip
Size: 11884 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/wtr-core/attachments/20051126/613f6164/guitest.zip

From sy1234 at gmail.com  Mon Nov 28 01:16:49 2005
From: sy1234 at gmail.com (Sy Ali)
Date: Mon, 28 Nov 2005 01:16:49 -0500
Subject: [Wtr-core] Administration of the new wiki
Message-ID: <1e55af990511272216s1117231eua2d6b037a8de9c2c@mail.gmail.com>

[from another thread]
On 11/17/05, Bret Pettichord <bret at pettichord.com> wrote:
> I'd like to see a backup administrator for the wiki, with whom you can
> share the access information. Any volunteers?


Right now we have the new wiki set up at http://watir.net although
that could be changed on request (e.g. to wiki.watir.com or
watir.com/wiki although I'd resist a subdirectory).

I'd like to set up a couple of core people to also have administrative
access.  Right now there are a few entry points into the setup, some
of which are and some of which are not needed.

At the moment there is one login and password to get into all
resources, but they can be separated.  There is, for now:

* ssh
* ftp
* mysql
* wiki

* ssh isn't really necessary for anything, including updating the software.
* ftp is necessary for all kinds of reasons
* mysql isn't something anyone ever needs to interact with.
* there are two kinds of wiki access types.. one which can and one
which cannot change other peoples access types.

So technically there could be different people set up to know the
back-end, and others who are cool with just the wiki side of things.

Let's begin the simple way.. everyone make yourself a user and
authorize the email receipt.  Then let's discuss who's comfortable
with wiki or server access.  I'd love to be able to hand over the
reins to a sysadmin type and just handle the wiki side of things.

Also, I'd like to have an ftp site somewhere where I can dump daily
backups.  I can do dumps onto my own computer, but I'm not quite set
up to do that yet.


From jeff.darklight at gmail.com  Tue Nov 29 01:13:41 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Mon, 28 Nov 2005 22:13:41 -0800
Subject: [Wtr-core] Patch for HEAD - Updated Frame#locate
In-Reply-To: <b539c61e0511282157o53ebf379jd5461478b8d547d3@mail.gmail.com>
References: <b539c61e0511282133w50ec8126gffc4acb966f88a03@mail.gmail.com>
	<b539c61e0511282157o53ebf379jd5461478b8d547d3@mail.gmail.com>
Message-ID: <b539c61e0511282213h7e16eb6cm5de9f7dc9cfea4e5@mail.gmail.com>

Ok, sorry for the confusion ... I had two small little errors ... all
better. and all working.  Please review & comment.

j.

On 11/28/05, Jeff Wood <jeff.darklight at gmail.com> wrote:
>
> Sorry, put a hold on that ... seems like I found a few new issues ...
>
> j.
>
> On 11/28/05, Jeff Wood <jeff.darklight at gmail.com> wrote:
> >
> > Ok, here's my submission for a patch to HEAD for the Frame#locate
> > function.
> >
> > It solves the bug with not being able to find iframes by anything other
> > than :index
> >
> > With this patch both frames and iframes are all now findable based on
> >
> > :index, :src, :name, or :id
> >
> > Let me know what you think.
> >
> > I haven't updated the testcases yet, but I did test it out manually (
> > good 'ol irb ).
> >
> > j.
> >
> > --
> > "Remember. Understand. Believe. Yield! -> http://ruby-lang.org"
> >
> > Jeff Wood
> >
>
>
>
> --
> "Remember. Understand. Believe. Yield! -> http://ruby-lang.org"
>
> Jeff Wood
>



--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051128/278bf34d/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: watir.rb.patch
Type: application/octet-stream
Size: 3850 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/wtr-core/attachments/20051128/278bf34d/watir.rb-0001.obj

From jeff.darklight at gmail.com  Tue Nov 29 01:37:49 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Mon, 28 Nov 2005 22:37:49 -0800
Subject: [Wtr-core] ... ok,
	hopefully final version ... patch : watir.rb & frame_test.rb ...
	Frame#locate mods for full Frame & IFrame support.
Message-ID: <b539c61e0511282237o3f9bd331ic20b01fc9339b5a5@mail.gmail.com>

Ok, attached is my patch against HEAD that supports :name, :index, :id, &
:src how attributes for both FRAME and IFRAME tags ...

Also included are patches for frame_test.rb to test this additional
functionality.

The only use case I didn't build and/or test ( but I don't see it anywhere
else either ) ... is what if a user pushes a regex for an index...

If we need to cover it, I can, but I figured this is/was a good start.

Review & Comments appreciated.

j.

--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051128/1a665657/attachment.htm

From jeff.darklight at gmail.com  Tue Nov 29 01:38:13 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Mon, 28 Nov 2005 22:38:13 -0800
Subject: [Wtr-core] ... ok,
	hopefully final version ... patch : watir.rb & frame_test.rb ...
	Frame#locate mods for full Frame & IFrame support.
In-Reply-To: <b539c61e0511282237o3f9bd331ic20b01fc9339b5a5@mail.gmail.com>
References: <b539c61e0511282237o3f9bd331ic20b01fc9339b5a5@mail.gmail.com>
Message-ID: <b539c61e0511282238q2d05e063teb526f91acccabdf@mail.gmail.com>

On 11/28/05, Jeff Wood <jeff.darklight at gmail.com> wrote:
>
> Ok, attached is my patch against HEAD that supports :name, :index, :id, &
> :src how attributes for both FRAME and IFRAME tags ...
>
> Also included are patches for frame_test.rb to test this additional
> functionality.
>
> The only use case I didn't build and/or test ( but I don't see it anywhere
> else either ) ... is what if a user pushes a regex for an index...
>
> If we need to cover it, I can, but I figured this is/was a good start.
>
> Review & Comments appreciated.
>
> j.
>
> --
> "Remember. Understand. Believe. Yield! -> http://ruby-lang.org"
>
> Jeff Wood




--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051128/ecdb36d8/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: watir.patch
Type: application/octet-stream
Size: 7394 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/wtr-core/attachments/20051128/ecdb36d8/watir.obj

From jeff.darklight at gmail.com  Tue Nov 29 14:49:11 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Tue, 29 Nov 2005 11:49:11 -0800
Subject: [Wtr-core] ... ok,
	hopefully final version ... patch : watir.rb & frame_test.rb ...
	Frame#locate mods for full Frame & IFrame support.
In-Reply-To: <b539c61e0511282238q2d05e063teb526f91acccabdf@mail.gmail.com>
References: <b539c61e0511282237o3f9bd331ic20b01fc9339b5a5@mail.gmail.com>
	<b539c61e0511282238q2d05e063teb526f91acccabdf@mail.gmail.com>
Message-ID: <b539c61e0511291149i198d90eeka6a382cd042ef492@mail.gmail.com>

so, everybody too busy to provide some feedback ?

j.

On 11/28/05, Jeff Wood <jeff.darklight at gmail.com> wrote:
>
>
>
> On 11/28/05, Jeff Wood <jeff.darklight at gmail.com> wrote:
> >
> > Ok, attached is my patch against HEAD that supports :name, :index, :id,
> > & :src how attributes for both FRAME and IFRAME tags ...
> >
> > Also included are patches for frame_test.rb to test this additional
> > functionality.
> >
> > The only use case I didn't build and/or test ( but I don't see it
> > anywhere else either ) ... is what if a user pushes a regex for an index...
> >
> > If we need to cover it, I can, but I figured this is/was a good start.
> >
> > Review & Comments appreciated.
> >
> > j.
> >
> > --
> > "Remember. Understand. Believe. Yield! -> http://ruby-lang.org"
> >
> > Jeff Wood
>
>
>
>
> --
> "Remember. Understand. Believe. Yield! -> http://ruby-lang.org"
>
> Jeff Wood
>
>


--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051129/395acfa0/attachment.htm