Beginnings of Action Trigger system and Evaluate Fields parameter issue

[ferdly]

Hi All,

I am just starting work on a "Action-Trigger" system.

Concept and Simple Example:

Have a table of Action-Triggers:

Action: Key to SWITCH script (If-{ElsIf...}{-Else}-EndIf block)

Trigger is the Calculation text that I wish to apply the Evaluate function to to return either "TRUE" (do the Action) or "FALSE" (don't do the action) I am having these be text values so that I can extend to things like "PROMPT" (see example)

Simple Example:

Motel with Sr. Citizen discount of $50 for those over 65 yrs of age.

In my Action Trigger table I add this record (very pseudo-coded so that the syntax is easier)

Action:

Sr.Citizen Discount

Trigger_algorithm:

Case(

IsEmpty(Customer::DOB); "PROMPT"

Year(Get(CurrentDate)) - Year(Customer::DOB) >= 65; "TRUE";

"FALSE")//won't sweat month/day for example

So when I check someone in it will loop through all my action triggers (well not all, there will be a "Type" attribute too, and only those for "OnCheckin") and gather the Evaluate(ActionTrigger::Action) result and if "TRUE" automatically create an account line item for the Sr. Citizen Discount and if "PROMPT" prompt the end user whether to apply the Sr. Citizen Discount (or better yet, prompt the end user for the Customer DOB and reevaluate).

This is much more extensible than a the customary "Checkbox" for Sr. Citizen or even an "Age" calculation and then manually check these descrete fields. Because then when you want to add an AAA ('Triple-A') Discount, you need to add another field, add another if-then step. With Action-Trigger all you need to do is add another record to your ActionTrigger table and another ElsIf block to your SWITCH script.

Indeed, you could extend (and simiplify) this by abstracting the system to have "general" tasks in the SWITCH script and gather the Specifics from the same ActionTrigger table. That is for the Sr. Citizen Discount record the "Action" attribute could be "Discount" the "Description" attribute could be "Sr. Citizen Discount" and the "Amount" attribute could be $50. Then when you add the "AAA Discount" Action Trigger record, you just make the Action "Discount", Description "AAA Discount" and "Amount" $25, and no need to extend the SWITCH script.

Pretty cool.

Of course, here I humbly welcome anyone to point me to an article/white-paper/web-tutorial and so on that already shows this so that I need not reinvent the wheel here.

Here is my problem:

How to work around the pesky Field List portion of the Evaluate function. (Evaluate(expression{;[field1;field2;field3;...]}))

I thought I could just have another attribute for "Trigger_fields" that I could use instead of the literal list of dependent fields. That didn't work. Then I found the GetFieldName() function and I thought that I would be able to use that within the Evaluate funtion and applied to my Trigger_fields. (One vs many problem to be worked out.) But when it didn't seem to work with only one I had to look elsewhere.

Note: I am not sure that this still isn't a possibility and I am just doing it wrong, so assistance with that is welcomed.

So, I went to the Get(ScriptParameter) ability within a Let() function for evaluate.

In this scenario, my Trigger_fields is a list of parameters in a string. That string can be set to a "$param" script variable and then have $param run through a Tokenizer script to switch out "{DOB}" with the customer's actual DOB value, an/or the Evaluate function can be applied to $param (I have tested this and it works, but I felt like I was weirdly recursing when I did this).

Then create a single step script that applies the Evaluate function with the $param value as script prameter.

$dob = {DOB} would become $dob = 2/12/1961 and then the Trigger_algorithm could then be:

Let( [" & Get(ScriptParameter) & "];

Case(

IsEmpty($dob); "PROMPT"

Year(Get(CurrentDate)) - Year(GetAsDate($dob)) >= 65; "TRUE";

"FALSE")//won't sweat month/day for example

)

This works. BUT -- I am pretty sure there is a better way...

Any thoughts?

Thanks in advance for any ideas.

[David Jondreau]

So you're storing your business logic in records rather than in scripts.

That doesn't seem advantageous enough to compensate for the loss in performance from using Evaluate() all the time, and the loss in time programming by coding all the field names, functions, etc by hand.

One of the strengths of Filemaker is how easy it is already to develop on. Adding a "AAA Discount" checkbox (or even better a field for AAA number) and the necessary scripting takes about 10 minutes.

If you expect to be adding some unknown discounts in the future, you build a table of discounts.

Too much wheel-reinventing for me.

[ferdly]

Hi DJ,

Thanks for your post.

There is a tradeoff, no doubt.

Finding the balance is always the goal of any IT project.

First, you mistated my goal. My goal is *not* to store my business logic in records rather than scripts. That connotes that it is my primary architecture. By my example that should be clear that is not my intent or my examples would be "Room Rent" or "Housekeeping Turnover". No, this is about non-primary and non-secondary, but tertiary issues that keep popping up and popping up that don't pop up because you didn't investigate or design to handle them, but because those kinds of tertiary things just do pop up, and they keep popping up. I thought it might be nice to solve that problem in the General Problem Space in a manner that is extensible rather than in the Specific Problem Space that will take only 10 minutes. (I recommend this Article -- about PHP, but the core concepts hold)

You are correct, adding an "AAA Discount" at the same time I add the Sr. Citizen discount is about 10 minutes.

(First, I am sure you understand that Sr. Citizen Discount and AAA Discount are two *extremely* obvious examples. The reality I have in mind are the myriad of esoteric things you have no way to anticipate[i trust that nobody not involved in hospitality knows that there is a thing called a 'corking fee'], but that said...)

Imagine you build a Sr. Citizen Discount, but you don't build an AAA Discount; then you deploy. Now a year and half later, when you have two other pressing deadlines, the client asks for the AAA Discount. Because you told yourself "It will take 10 minutes if they want something else" you now have a Real Estate issue of where to put that checkbox or member number field, you have to add an If-Then to your checkin script? where is that script? where in that script is the Sr. Citizend Discount? you can't remember, you place it in the script you built for Checking-In rather than in the Transaction script because you can't remember so the logic only gets checked upon checkin and if the number is added during the stay it doesn't get noticed at checkout where it should also be checked again (as happens with the Sr. Citizen Discount) so you get another call -- so now your 10 minute script fix has turned into a 4 day headache and you have pissed off three clients.

Personally, I would rather solve the "Discount" problem generally with an Action-Trigger system. Then a year and a half later I only need to add another record to an existing table and it is handled. I could even figure that out remotely and email the client the field values to use for the new record (this would be the "IT comfortable contact" if there is one).

Further, I can reuse an Action-Trigger system with my Dentist client, I can reuse an Action-Trigger system with my Heath Club client, I can reuse an Action-Trigger system with my real-estate client. And I can use it not just for discounts, but for Late Fees, Exception Reporting, "Rewards Point" tracking, course prerequisite checking, scheduling conflicts.

Indeed, when the client calls a year and a half later I won't have to wonder where to look, because I will have been using (and honing) this system with my clients over that time -- perhaps the client would like an Upgrade to what it has evolved into (more bill-ables, not just a bug-fix).

What I am trying to do is solve the general problem ONE time in a manner that is extensible and reusable rather than condemn myself to a lifetime of 10 minute fixes. I already have enough of them, thank you, and they have become a "velvet trap".

But you are correct about adding a Checkbox and a script -- FileMaker makes it easy. Action-Trigger isn't easy.

You are, respectfully, incorrect about "you build a table of discounts" -- that is the *point*! You *don't* build a table of discounts and then a table of fees and then a table of additional charges and then a table of special needs (crib, bed-board) and then a table of... you build a table of "Actions" with an attribute of "Type" for "Discount", "Fee" "Additional Charge", "Special Need" respectively.

All my post was about was to request help in including a "Trigger" portion to that table.

I am really less interested in defending my intentions than getting help solving the problem. So, please understand that I have made the decision that I am going to solve the General Problem rather than to continue to be a "10 minute fix" guy. I am not going to change my mind. If you or anyone reading this have any information on how others have done this, or the specific problem of abstracting the "Fields" portion of the Evaluate() function I would still be very interested in any assistance you can offer.

Thanks again for the response,

Brad

[bruceR]

Quite interesting.

[David Jondreau]

You seem pretty set on your way of doing things and have a lot of time on your hands. But I am simply not seeing your vision clearly. I don't actually understand what you're asking.

Why do you need to deal with the optional field list at all? The purpose of that field list is to trigger Evaluate() in a calculation when one of those dependent fields changes. But you're calling Evaluate() explicitly by script, why do you need to trigger it with Eval or Let?

I'm pretty sure you're in uncharted territory, good luck.

When I want a central repository for code, I use the custom function space.

[bruceR]

It would be quite helpful if you would provide a simplified example file.