-
Notifications
You must be signed in to change notification settings - Fork 6
Conversation
Looks good. Do you need any help on the Ruby side? |
I've got a starting point for the ruby, I suspect I'll need to you tidy it up and "rubify" it though. I've started with:
In the ArgumentList class, and proved that I'm getting that passed through to the tcl. Given that it's not in a "tcl" format, I suppose I should modify it in the ruby first before passing it through... I'll have a go at that next. |
Yeah that looks right. I think there's one spec for the StepDefinitions class, so you might be able to use that if you want a smaller lever. Run the specs with I think that |
I think this will come back to the old tcl phrase of "everything's a string" - In the tcl, I'm getting: [["first_column", "second_column"]] I need to find out how to turn a string into at least a list so I can try to do something with it... |
Ok, I've got something that kind of works in tcl, although I'm not that pleased/proud of it:
That results in a tcl list of lists which I can work with (arrays in tcl are a bit of a pain). I was thinking that in the "raw" form, a list of lists would be a good start, and then for getting hashes, we can use a dict. It's pretty messy using regsubs (and likely to break as soon as there is a table with any of these characters in). Do you think it makes more sense to get the ruby to pass through the data in "tcl list" format - i.e. to convert:
into
? |
80dfed8
to
ccfeb92
Compare
@jowers this makes the ruby code neater. Is this OK to parse on your side?
@jowers do you think this will do for now, if we tidy up the commits? I think we could add the table helper methods in later iterations. |
Yep, I think so. |
I think we're ready to merge this one back. I've added a section to the README explaining the use of tables in step definitions (as a side note, we probably need to edit the README as it's now a bit sprawling and could do with a few sub-headings - I suspect my use of tenses is all over the place). Does the automatic merge thing in github do all the squashing of comments for you? |
Yes, I think it's ready. The GitHub merge button does not squash commits. If you want to use that, the right thing to do is to use |
Otherwise, just use |
Ok, merged this one as well. I guess I should do another release now that we have these 2 in place. IIRC, I need to do the following for that:
Is that all, or have I forgotten something? |
It's |
Always a good idea to put release instructions in |
Ref #14. Great minds @aslakhellesoy
Yeah so @jowers if you look in https://github.com/cucumber-ltd/bbc-a11y/blob/master/CONTRIBUTING.md you'll see what you need to do to get release karma. |
I've just released v0.0.4 to rubygems. Closing pull request. |
\o/
|
I've added a failing feature for this one - I think we'll need a few more features, but I've kept it simple for now - just a single row. I've also guessed at a tcl proc name - I suspect that will have to change once I've thought about it a bit more.
The other types that I think we'll definitely need are:
and, of course, something with multiple values in: