CMS Design with jQuery and PHP: postage and packaging prices
This article is based on work which will be expanded more fully in the book, when I get to that chapter.
Every time we do an online store here in webworks, the postage/packaging is different. In one case, for example, postage is free over €50 euro, in another, it depends on where it’s going, and in the latest, it depends on a load of factors including where it’s going, what the weight of the products is, and what delivery option was chosen.
Up until now, hand-coded the postage rules. Everything else was handled by user-friendly parts of our CMS, but postage was such a random thing that we couldn’t find anything common enough that we could make a generic P&P handler.
The finished product is more complex than this example, but I’ll describe a cut-down version of what we’ve done, with countries and parcel-types removed.
admin demo – demo of UI for generating P&P rules
The first demo shows how the postage-and-packaging rule-set is created, using an “if-else” flow generator to build up the logic of the thing, and after each major action, convert the current state into a JSON string which can be saved.
The PHP is not really important in this one. The JavaScript handles everything. It translates a “seed” JSON string into a graphical representation of the rules, which can then be manipulated and finally translated back (automatically) into a JSON string to be saved in a DB (or session in this case). source for the PHP, source for the JS.
The frontend does its work in the background:
frontend demo – using those rules to evaluate P&P (visit admin first).
In this case, we enter values – total, weight – and run through the rule-set to find out what the P&P ends up as.
The source is suprisingly small, using a small recursive function to dig through the rules, no matter how deep and complex they go.
Here’s the recursive function (see source for rest of file):
function os_getPostageAndPackagingSubtotal($cstrs,$total,$weight){
foreach($cstrs as $cstr){
if($cstr->type=='total_weight_less_than_or_equal_to' && $weight<=$cstr->value)return os_getPostageAndPackagingSubtotal($cstr->constraints,$total,$weight);
if($cstr->type=='total_weight_more_than_or_equal_to' && $weight>=$cstr->value)return os_getPostageAndPackagingSubtotal($cstr->constraints,$total,$weight);
if($cstr->type=='total_less_than_or_equal_to' && $total<=$cstr->value)return os_getPostageAndPackagingSubtotal($cstr->constraints,$total,$weight);
if($cstr->type=='total_more_than_or_equal_to' && $total>=$cstr->value)return os_getPostageAndPackagingSubtotal($cstr->constraints,$total,$weight);
}
$val=str_replace('weight',$weight,$cstr->value);
$val=str_replace('total',$total,$val);
$val=preg_replace('#[^0-9*/\-+.\(\)]#','',$val);
if(preg_match('/[^0-9.]/',$val))eval('$val=('.$val.');');
return (float)$val;
}
The switch block goes through the various “if” types that can exist in the flow model, handling each of them recursively and return their values to the caller.
If no “if”s are encountered, then the ruleset has found an answer, and we return that answer.
Before returning it, though, we parse the value of the answer. This is in case the answer is a math formula to do with the weight or total of the item.
For example, An Post have definite prices for packets to Europe up to 2kg (which is 10.75), and beyond that, it’s 3 euro extra for every extra kg.
That translates to a load of definite “if” statements, and an end value of “(weight-2)*3+10.75” for the final “else”.
So, we convert recognisable words such as “weight” or “total” to numbers, make sure that we’re only left with parseable characters (and not something that can be used to hack), and eval it to produce the result.
Obviously, the full product is more complete than this, with safeguards against faulty formulas, extras to handle countries and envelope types (parcel/packet/envelope), but this example should give you a few ideas if you’re building your own P&P handler.
and then view