On 5/15/07, Bret Pettichord <[EMAIL PROTECTED]> wrote:
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?
Hi, I did just start a new job - so far so good! - and I had initially wanted to get everything done before the change. That said, I feel like I could accomplish a good bit more in 2-4 more hours work, and I can tell that I have the time and the brainspace to do that within the next week.
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?
Ahh. No, I'll change that. I figured that as we go I would learn more about what works where.
> *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.
Ok, thanks. I'll take a look at the rakefile.rb and try to add these. If I have questions I'll post'm to the list. (And once I understand it I'll note this in my rdoc how-to page on the wiki.)
> 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.
Will do.
> * 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.
Cool. I'll do this as well.
> 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 think consolidating it is the right choice. If it would be helpful, I'll try to take a first whack at this by the beginning of next week as well. I'm sure whatever I make will/would contain inaccuracies (e.g. my not knowing that the multiple attribute support only for non-input elements) but if my creating a first draft would help I will see what I can put together between tonight and this coming Wednesday. 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.
Thanks. I'll do the next one that way. 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.
Ahhh. I haven't used it myself. I am happy to take out the example. Should we stop listing it altogether? I'll send a seperate email to the list to see if folks are using it, and for conversation about how much it should be supported and or removed. Thanks, Jeff -- http://testingjeff.wordpress.com
_______________________________________________ Wtr-general mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-general
