Updates:
Summary: Regular expression support for embedded argument syntax
Status: Accepted
Labels: bwic
Comment #1 on issue 854 by pekka.klarck: Regular expression support for
embedded argument syntax
http://code.google.com/p/robotframework/issues/detail?id=854
We decided to implement embedded arguments support (a.k.a. BDD style) so
that users can specify arguments as normal variables because regexps are
more complicated and most of the time they are an overkill. The example
provided in the original report very well illustrates that there are
situations where this simple approach doesn't work.
The proposed solution in the issue description is also very good -- or at
least I though about similar solution after reading the beginning of the
description. I think this could be implemented so that if you have
something like `I execute "${x}"` we automatically generate regexp `I
execute "(.*)"` like we do nowadays, but if you specify regexp yourself
like 'I execute "${x:\d+}"` we use that regexp like `I execute "(\d+)"`.
This ought to be pretty simple to implement and also nearly backwards
compatible. The only backwards-compatibility issue (and the reason I added
`bwic` label) is that if someone has used the separator between the
variable and the regexp in their variable name things would break. This
shouldn't be a big problem in practice if we use colon as a separator as
originally proposed, but we could also use something like a double colon
(${x::\d}) or pipe (${x|\d:}). For some reason, I don't really know why, I
would actually prefer the pipe myself.
Another small detail to think is should we require backslashes in the
regexp to be escaped similarly as elsewhere in the test data. It could be
that keyword names are handled so that we must require escaping, but it
might be more consistent if we would require them even if that wasn't
technically necessary.
If you imranoft really are willing to help implementing this, getting this
into 2.6 ought to be possible. As I already wrote this ought to be pretty
easy to implement and I'm also sure we can find an agreement for all small
open issues.
