Re: Issue 38 in osmo: repo is forked

[Teemu Kanstrén]

Did you have some specific issues with implementing the group field? It is always useful to know before trying it myself.

It might also be more clear to just use the guards as you did but instead of matching them to specific test steps/transitions match them to groups always. Not sure what that would mean for the test step definitions though. 

Generally what I like about the current approach is that it is simple and readable. Once it starts requiring several fields in the annotations it starts to get a bit more complicated.

Have to try and see I guess. 

On 13 March 2013 11:08, Tamás Kende <olio...@gmail.com> wrote:

I tried to use another field for group but I have failed during the implementation. But of course you can do it better. 

---------- Forwarded message ----------
From: Teemu Kanstrén <tkan...@gmail.com>
Date: 13 March 2013 10:47
Subject: Re: Issue 38 in osmo: repo is forked
To: codesite...@google.com

OK, I see what you mean. The groups are a nice way to associate guards to transitions in a more abstract way. I will look at your implementation and see how to best integrate it to the code. I think requiring an explicit definition of group="groupname" might be more clear to make a distinction.

On 13 March 2013 03:35, <os...@googlecode.com> wrote:

Comment #2 on issue 38 by oliol...@gmail.com: repo is forked
http://code.google.com/p/osmo/issues/detail?id=38

Hi,

thanks for your answers!
About the grouping: I created this to make it easier to group those transitions what requires the same guard. We often had a situation when a guard looked like this:
@Guard({"login","doThis","doThat","doWhatever"...}) so now you can create a group in the trasition: @Transition(group="A") and in the guard it is enough to say: @Guard("A"). But I think I created a test for this... This is not the best implementation, because from the guard it is not clear is it for a group or for one transition, but better than nothing :).