Answers to: Signal wildcards behave in an unexpected way

Comment by Reguel Wermelinger on Reguel Wermelinger's answer

Reguel Wermelinger — Fri, 17 May 2019 08:37:20 -0400

Your suggestion is what we had for several sprint in place and was actually our first approach. Based on the feedback we got back then we switched to prefix matching without the explicit wildcard to ease listener definitions (users got annoyed by the repetitive asterics definition work). However, now we can't easily change that behaviour without braking existing workflows. But I guess that in most cases you can easily work around that behaviour if you dont like it.

Comment by vagabond on Reguel Wermelinger's answer

vagabond — Thu, 16 May 2019 10:58:38 -0400

Hi Reguel Wermelinger, in my opinion, if I define a signal receiver to listen to only:this, then only a SignalCode of only:this can trigger it. If I want the current behavior, I'd define only:this:*. To me, this is more intuitive.

Answer by Reguel Wermelinger

Reguel Wermelinger — Wed, 15 May 2019 09:44:43 -0400

Hi Jack

that the signals are fired here is expected. Signal codes are hierarchical and can be used pretty much like package names in java. the idea is that one fires acme:cool:wf:customer:signed:up:3424 and starts can listen to this signals by using a parent code: e.g. acme, acme:cool, acme:cool:wf, acme:cool:wf:customer, acme:cool:wf:customer:signed, acme:cool:wf:customer:signed:up the wildcard at the end is not necessary. But it is required if a listener should react to wildcards on the left side of the code: *:cool:wf:customer is a valid example of a wildcard.

But I see 2 problems exposed by your question:

signal wildcards are currently documented in a misleading way in the designer guide. So I'll try to clarify this chapter.
and we allow to inscribe patterns such as acme:* but at runtime these starts are not fired. That's a bug in my opinion. Not important as you can easily skip the wildcard and have the result you'd expect. But I'll address it in XIVY-3220.