[Home]

Summary:ASTERISK-07518: Alternative to naming new extensions when building a switch conditional
Reporter:Sherwood McGowan (rushowr)Labels:
Date Opened:2006-08-10 18:52:06Date Closed:2006-08-14 10:03:36
Priority:MinorRegression?No
Status:Closed/CompleteComponents:PBX/pbx_ael
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Hey Murf, it's your favorite AEL2 bug reporter/nitpicker... :)

While viewing the output of the new -w option for aelparse, I noticed that you convert switch cases into new extensions within the context. I wanted to offer up another possibility for building this out so that it doesn't require changing the extension.

Have you thought about just using n(labelname) directives? See the additional information box for my examples/comparisons.

the n(label) labels are GREAT, and you can reference them just like we do within the AEL code :)

Anyway, just a thought.

****** ADDITIONAL INFORMATION ******

AEL2's outputted code: (excess removed)

[macro-endcall]
exten => s,1,Goto(sw-10-${calltype}|1)
exten => s,2,NoOp(Finish switch-endcall-10)
exten => sw-10-in,1,Macro(setdispo|${callid})
exten => sw-10-out,1,Macro(dbconn|cdr|open)

A suggested way to do this:

exten => s,1,Goto(${EXTEN}|${calltype})
exten => s,2,NoOp(Finish switch-endcall)

exten => s,n(in),Macro(setdispo|${callid})
exten => s,n,Return

exten => s,n(out),Macro(dbconn|cdr|open)
exten => s,n,Return
Comments:By: Tilghman Lesher (tilghman) 2006-08-10 22:38:19

Again, feature requests are to be filed on the Wiki.
By: Sherwood McGowan (rushowr) 2006-08-10 23:57:42

Corydon76l:

This is _NOT_ a feature request, it's a suggestion for an improvement to Murf's existing code. Granted I don't have a patch or solution to offer, but the suggestion is a valid one, as the existing method of using multiple extensions to separate cases within the switch statement is not the best.

Cheers
By: Serge Vecher (serge-v) 2006-08-11 09:12:02

rushowr: we [the bug marshalls] are trying to make sure that the bug-tracker is optimally used as a tool to track current bugs in Asterisk code. Over time we have found that issues requiring some discussion, i.e. feature requests or code optimization/tweaking/improvements are not very well suited for the bug-tracker due to limited exposure (but asterisk-dev list or #asterisk-dev channel on IRC are).

I'm saying this not to discourage the wonderful job you have been doing with murf on ironing out the bugs and bringing in enhancements to AEL. I'm hoping that my input will give you another perspective that will help you make the best use of all resources the Project/Digium has available to foster development.

Thanks.
By: Steve Murphy (murf) 2006-08-14 08:31:54

Email exchange:

to rushowr, from murf:

As to the switch thing, as I call it...

I have definitely thought much on this issue while I was coding up AEL2...
but first and foremost, that was the way (using separate
extensions) the original AEL implemented switches, and
I didn't want to rock the boat.

Next, it does have a certain appeal. Besides the normal case and default
statements you can put in a switch, there is also the "pattern"
statement, which basically is just like a case, except that it prepends an
underscore in front of the extension name, allowing a pattern extension,
which is something you just cannot get with a simple switch...

switch(${NUMTODIAL})
{
       case 911:
               verbose("Hey, an emergency!");
               break;
       case 411:
               verbose("What, you need information?");
               break;
       pattern 307XXXXXXX:
               verbose("Why on earth would you want to call Wyoming?");
               break;
       pattern 801XXXXXXX:
               verbose("Why on earth would anyone call Utah?");
               break;
       default:
               verbose(Ah, a discriminating caller, indeed!);
               break;
}

I guess if labels could define patterns, you could get the same affect.
Until then, you have to admit, the pattern statement is a nice feature.

Response:

Hey, you're right! I completely forgot about the pattern matching abilities.
Your way definitely makes much more sense :)
By: Steve Murphy (murf) 2006-08-14 08:38:02

Just for completeness, I recorded the email exchange on this issue as a note. I think in the future, we will use the AEL2 wiki page as a sort of AEL2 blog, where I'll keep a running record of bugs reported/fixed, and enhancement request history... anything I see in IRC or asterisk-dev mailing list, I'll record there.
By: Serge Vecher (serge-v) 2006-08-14 10:03:36

murf: I agree, I think the wiki page is the best resource for history/current state tracking...