Jeff, Thank you for the patch. I have committed to SVN. Your changes will be included in the next development gem.
In your note, you call this a project report, suggesting that you plan to continue this work. But i also seem to recall you making a statement earlier that you were starting a new job and might not have much more time for this. Could you clarify? Further comments are contained inline below. Jeff Fry wrote: > ** > watir.rb > > * Updated button method with additional hows (:class, :text), > additional Typical Usage, examples of accessing an element with > multiple attributes, and an example of accessing a button nested > within another element. (I am considering whether to do this for > all Elements, or to use a different tactic. See my questions, > below.) > I don't think this example works. Specifically, multiple attribute support is currently only implemented for non-input elements. Please let me know if you would like to change this? > > * Other minor, mostly typographical changes > > > *Questions: > *changes.rb and license.rb > > * What do I need to do so that these will be listed in the rdoc > (as they are for rspec and rails)? When I rolled my own rdoc, I > don't see these under Files. > This is controlled by the rdoc task definition in the rakefile.rb. Note that some of this is defined indirectly, ensuring that the gem creates rdoc that looks the same as that created by the rakefile. > > changes.rb > > * This list is all features, improvements, and bugs listed in Jira > for Watir 1.5, with a resolution of fixed + unresolved ones. It > excludes tasks, sub-tasks, and anything with a resolution other > than fixed. Is this what we want? > We have also been detailing change information in the Wiki News section. http://wiki.openqa.org/pages/viewrecentblogposts.action?key=WTR It would be nice if this information were folded with the information you pulled from Jira. > > * All all our new features included on this list? (e.g. It seems > that modal dialog support is NOT obviously a part of any of > these features or improvements. Do we have new features without > corresponding Jira items?) > Yes we do. We actually create the change reports for the 1.5 development gems from the commit logs, not directly from Jira. If you want to go back before 1100, you can look at the commit logs. Everything is actually in there. > > watir.rb > > * :method and :action are listed as permissible 'how' types for > the initialize method. What do they mean? Where else are they > usable? > I believe these only apply to Form elements. > > * Think about how best to lay out hows & whats. Please comment. > o The current strategy is to list every how value for each > element, with usage hints. (My edits to button are in > keeping with this strategy.) > + Benefits: This has the benefit of having a lot of > information right by each Element method, including > examples specific to that Element. > + Downside: more work to maintain in multiple places, > and more opportunities for information to get out of > sync. > o An alternate strategy (mentioned by Brett in an earlier > email) would be to centralize this information - somewhere > in the rdoc or on the wiki - with links to it from each > Element. > + Benefit: easier to maintain, can't get out of sync. > Also a less verbose rdoc. > + Possibly not as clear for someone unfamiliar with Watir. > Unless someone volunteers manually keep all the duplication in sync (Maybe you are volunteering to do this -- it's not clear to me), then I plan to consolidate it so that it is at least accurate. Right now, it is easy to read (somewhat) but incomplete, which is pretty bad. > > I've attached a patch of all the changes I've made so far so that > interested folks can check it out. (BTW, this is the first patch I've > created, and I was surprised to see that it's just a txt file. If this > /isn't /correct, please let me know. I created it using these > instructions > <http://svn.collab.net/subclipse/help/index.jsp?topic=/org.tigris.subversion.subclipse.doc/html/reference/create-patch.html>. BTW, the best way to post a patch file is to attach it to a Jira ticket -- either an existing one or a new one. Then the ticket can be used to track progress on the patch. When we have commits based on tickets, we include a link to the ticket in the commit message, which helps keep everything easy to track. One final comment. I saw you included an example for :afterText. But i'm not really sure how and when :afterText works, have seen some complaints about it, and am unsure whether we should be encouraging people to use it. Bret _______________________________________________ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
