On Wed, Apr 22, 2009 at 2:27 AM, Jonathan Linowes <jonat...@parkerhill.com>wrote:
> no offense to anyone here but all this is starting to remind me of the days > of green ASCII terminals... there's a reason gui's, wysiwyg editors and > typographic fonts were invented...ok, nevermind, back to plain text, > proportional font, character chart art .... > :) > Text is king. It's always possible to build GUIs on top of text. And that will happen with Cucumber. One of FIT's biggest flaw (IMO) is that it doesn't have an underlying format below HTML (too high level). Ok - let's not derail the table discussion in this thread. > > > > On Apr 21, 2009, at 6:50 PM, Nigel Thorne wrote: > > Here is the same thing as a gist http://gist.github.com/99443 > 2009/4/22 Nigel Thorne <rs...@nigelthorne.com> > >> I would prefer it to be explicit what columns I am using, that way if you >> have two steps that require this technique in your scenario it still >> works.Relying on an implicit 'the rest' doesn't work in that situation. >> In my scenario I would like to have something like this.. >> >> Given I am logged in as <Role> >> And I have a Protocol <Initial Protocol Details> >> >> When I clone the protocol >> Then the new protocol will contain <Cloned Protocol Details> >> >> >> >> >> Examples: >> >> *| Role | Initial Protocol Details ||| Cloned Protocol Details >> ||| >> >> >> *| | Name | Urgent | Description | Name | Urgent | Description >> | >> >> >> | Admin| Prot1 | Y | Protocol 1 | Prot~1 | Y | Clone of Protocol >> 1 | >> >> >> | Admin| Prot1 | N | Protocol 1 | Prot~1 | N | Clone of Protocol >> 1 | >> >> >> etc. >> >> >> Here I am using ||| to signify the number of columns that are included in >> the above grouping. Not sure how best to indicate which rows are header >> rows. >> >> WDYT? >> >> >> 2009/4/22 Ben Mabey <b...@benmabey.com> >> >> aslak hellesoy wrote: >>> >>>> >>>> >>>> On Tue, Apr 21, 2009 at 10:20 PM, Joseph Wilk <j...@josephwilk.net<mailto: >>>> j...@josephwilk.net>> wrote: >>>> >>>> On Tue, Apr 21, 2009 at 7:32 PM, Jonathan Linowes >>>> <jonat...@parkerhill.com <mailto:jonat...@parkerhill.com>> wrote: >>>> > >>>> > On Apr 21, 2009, at 1:57 PM, Joseph Wilk wrote: >>>> > >>>> >> What you really want is an examples table that is embedded in a >>>> step >>>> >> (different from a step table, maybe by keyword?) that causes >>>> the step to be >>>> >> run multiple times for each of the values. So rather than using >>>> placeholders >>>> >> we embedded a Examples table in the step. >>>> > >>>> > >>>> > like this? >>>> >>>> Not quite, I was thinking of running the whole scenario for the >>>> examples step table rather than just the step. >>>> >>>> However I really like Ben's suggestion of a sub-table >>>> (http://gist.github.com/99255). >>>> >>>> I think it would be conceptually easier for a non-technical user to >>>> grasp than my first suggestion which makes it a big win for me. >>>> >>>> >>>> Thanks a lot for all the suggestions so far. I like Ben's subtable too. >>>> In the example: "I should be presented a menu with <Meat Options>" I >>>> assume the step definition would be: >>>> >>>> Then /I should be presented a menu with/ do |meat_hash| >>>> # meat_hash has the following value the 2nd time (Jewish): >>>> {'Pork'=>'N', 'Lamb'=>'Y', 'Veal'=>'Y'} >>>> end >>>> >>>> However, having the <Meat Options> as part of the step would be >>>> inconsistent with how the regexp matching is currently working. >>>> >>>> Here is an alternative: http://gist.github.com/99376 >>>> >>>> The idea is that we add a new kind of multiline argument in addition to >>>> pystrings and tables: Hash. This is >>>> done using the familiar <> delimiters as a multiline argument. What's >>>> inside it has no significance other than documentation. >>>> The keys of the hash would be the same as the Examples table header >>>> *minus* the columns that are referred in other steps. >>>> >>>> In essence it achieves the same as Ben's, but relying on a convention >>>> (removing referenced columns) rather than introducing >>>> a new, more complex table markup. >>>> >>>> WDYT? >>>> >>> >>> Interesting.. so your meat_hash was derived from the columns of the table >>> that were not used previously in the scenario? Meaning, that is why >>> Religion was not part of your meat_hash. >>> >>> That makes sense, and.. since the scenario outline is parsed before any >>> of the examples are ran through that convention could be maintained no >>> matter what order the delimiters appear in the scenario. (Just thinking out >>> loud here...) >>> >>> Yeah, I like it. I also agree with Matt about meat_hash. All this >>> meat_hash talk is making me hungry... >>> >>> However, what if people wanted multiple hashes? Subtables would allow >>> for this but a single hash solution would not. FWIW, here is a very >>> contrived exampled: >>> >>> http://gist.github.com/99424 >>> >>> I agree that the sub-table is probably adding too much complexity, >>> especially since we have a simpler alternative and no real use cases for it >>> yet. Basically, you can ignore that last gist, I was just experimenting >>> with contrived use cases. :) >>> >>> >>> -Ben >>> >>> >>> >>>> Aslak >>>> >>>> >>>> -- >>>> Joseph Wilk >>>> http://blog.josephwilk.net >>>> >>>> > >>>> >>>> https://rspec.lighthouseapp.com/projects/16211/tickets/149-step-outline >>>> > >>>> > _______________________________________________ >>>> > rspec-users mailing list >>>> > rspec-users@rubyforge.org <mailto:rspec-users@rubyforge.org> >>>> > http://rubyforge.org/mailman/listinfo/rspec-users >>>> > >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users@rubyforge.org <mailto:rspec-users@rubyforge.org> >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users@rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> >> > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users