Using Evaluate function in Sep Model with BL file

[Razumovsky]

Hi all,

I am at the very beginning of this concept, but thought I would put it out there in the brain pool and see if anyone else had tinkered with it:

I really like the idea of a BusinessLogic file, but have not seen or come up with any implementations of it that I find practical or useful. I recently had a thought that might be productive in this endeavor.

The idea is to have the BL file be a single record with scores of global text fields. I would still have most calcs in the datafile, but each calc would only be something like:

evaluate(BL::gText1; [ModificationDateTimeStamp])

The idea being a developer could update, alter, or add calculations directly in the text fields in the BL file wihtout having to mess with the data file, and without duplicating recordsID's in the BL file.

I have to admit that I have not used the eval function that much and am not quite sure what problems to look for yet (will it be searchable? Updating issues? Performance over a network? etc)

So, what does everyone think; possible epiphany or tangential timewaster?

-Raz

[T-Square]

I don't quite think this is an epiphany, but I am probably wrong...

The problem with putting calculation fields in the datafile at all is that if you have any need for a new calculation, it's got to go into the back end, which then puts your client or you in a difficult spot of taking down the database to update the backend.

Or are you suggesting that you create a single calculation field in the back end that uses a generic set of commands stored as records in the BL file? In that case, I imagine it would work better to put a Calcs table in the BL file that would have separate records for the different calculations. In other words, the table would store the contents of the function. I presume you'd have to write a custom function that would parse the data field with the calculation text. But I am not sure how you'd go about triggering the different functions in the Calcs table.

Maybe an aggressive use of custom functions could work around this in some way? Just thinking out loud here.

David

[Razumovsky]

Hi David,

The problem with putting calculation fields in the datafile at all is that if you have any need for a new calculation, it's got to go into the back end,

Well, yes and no. I have gotten in the habit of including dummy placeholder fields in the datafile in anticipation of having to use them later on (see my post at the end of this thread here ). However, I didnt do this with calculations as these placeholder calcs couldnt be edited/updated through the UI file. This is where I am thinking the evaluate function might be handy.

Or are you suggesting that you create a single calculation field in the back end that uses a generic set of commands stored as records in the BL file?

No.

the table would store the contents of the function.

Exactly, but in globals, not in individual records (so they can be called from any table in the Data file without using relationships).

There would be one global text field in the logic file for each calc field in the data file. Like, in the Invoice Data file:

cSubTotal=

evaluate(BL::gSubTotal;ModificationDateTimeStamp)

cTax=

evaluate(BL::gTax;ModificationDateTimeStamp)

cTotal=

evaluate(BL::gTotal;ModificationDateTimeStamp)

And in BL file, the text globals would store the contents of the calcs (note that I am using quotes here just to illustrate that it is plain text typed into the field. The quotes would not be actually in the fields or else the eval function would return the contents as a text string):

gSubtotal =

"Sum(LineItems::Price)"

gTax=

"cSubtotal * .085"

gTotal=

"cSubtotal + cTax"

The ModificationDateTimeStamp would be the trigger field that would force the calc to re-evaluate every time a record was changed.

It might be possible to use this as well as placeholder fields to allow a fair amount of flexibility in changing and adding calcs on the fly. Although, I admit that I am becoming more skeptical the more I think it through - fields would be unindexable because they reference a global for one. I will try and tinker with this this weekend (but have that sinking feeling that there goes my saturday...).

-Raz

[Razumovsky]

Edited- doubleposted

Edited March 9, 2006 by Guest
ack, double posted!

[Razumovsky]

Okay, I couldnt wait. It actually works quite well, and is searchable! My only complaint is that it will not update the calc until the record is comitted.

David-

You also got me thinking about scripting something into a nav script that would set a single global in the BL with whatever calc text would be used for that particular layout. You then could have only one (or very few) calcs in the data file that was placed on each layout whose function would be completely dependant on whatever context you wanted.

*Added- Just thought that perhaps incorporating a

case(get(LayoutName)=Layout1; gLayout1calc;

get(LayoutName)=Layout2; gLayout2calc;

get(LayoutName)=Layout3; gLayout3calc;...)

into the calc text might eliminate the need for any scripting in this regard...*

Here is a quick mockup. I combined the UI and BL files for speed, but you can see how they could easily be separated (sorry for the starkness, the design team is out sick today...). Open the LogicUI file.

I am actually getting excited again, but need to get back to work. I am definitely going to pursue this later though.

-Raz

BLTest.zip