[ic] postcode field in state database

[Mike Heins]

Quoting Jeff Fearn (jefffearn at gmail.com):
> On 4/12/05, Mike Heins <mike at perusion.com> wrote:
> > The way to do this is probably to use an OrderCheck code definition
> > instead of modifying Order.pm. (They take precedence over the ones
> > defined there.) If you make a compatible one, we can put this in
> > code/Ordercheck instead of in Order.pm (which is sort of the direction
> > we are going with this stuff anyway.
> 
> I created MultiPostCode.ordercheck and MultiState.ordercheck files and
> they are both working ok.

Caution on naming -- I am not sure mixed case is best unless it
is just for you.

> 
> Does moving the code to these two files overcome Jon's concern of
> referencing a database  or column by name? Or is there a better way to
> access this data?
> 

Of course, if it is not to be distributed with the core.

We try to discourage people from hacking on the core, since there is
almost always a way to add these types of features without doing
it. Hacking the core makes upgrades a nightmare, and I bet there
are a lot of people running 4.9.x for just such a reason. I
developed catalogs for 4.9.x and when 5.x versions come out, I just
upgrade over the top and it is almost always trouble-free.

With 5.x and its distributed widgets, order checks, filters, action
maps, form actions, and tags, you can do just about anything simply
by defining your own thing and using it.

If you want to contribute these, you would need to 1) agree
to let me hack on them prior, 2) make the code compliant, or 3) submit
them to eg/ instead of the core.

To make them core-ready, we typically do stuff like the below (from
the country_select widget I just did).

That uses the ExtraMeta to allow you to set those types of things from
the admin UI.  In the case of an OrderCheck which doesn't have associated
metadata, you would probably use Variable values like MULTISTATE_TABLE
and MULTISTATE_FIELDS. It can get a bit ugly, so I think that putting
it in eg/ would be easiest.

Another alternative would be to test for the existence of a compliant
state table and fall back to the standard check if it is not present.

## begin clipped code
    my $stab = $opt->{state_table} || 'state';

    my $csort = $opt->{country_sort} || ($opt->{no_region} ? 'name' : 'sorder,name');
    my $ssort = $opt->{state_sort} || 'country,name';

    my @csort = grep /\w/, split /[\s,\0]+/, $csort;

    my $csort_sub = sub {
	    for(@csort) {
		    my $so = $a->{$_} cmp $b->{$_};
		    return $so if $so;
	    }
	    return 0;
    };

    my @ssort = grep /\w/, split /[\s,\0]+/, $ssort;

    my $ssort_sub = sub {
	    for(@ssort) {
		    my $so = $a->{$_} cmp $b->{$_};
		    return $so if $so;
	    }
	    return 0;
    };

    my $cdb = dbref($ctab) or return $die->('country table %s not found', $ctab);
    my $sdb = dbref($stab) or return $die->('state table %s not found', $stab);
    $ctab = $cdb->name();
    $stab = $sdb->name();
    my $cq = "select * from $ctab";
    my $sq = "select * from $stab";
    my $cary = $cdb->query({ sql => $cq, hashref => 1});
    my $sary = $sdb->query({ sql => $sq, hashref => 1});
## end clipped code

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.647.1295  tollfree 800-949-1889 <mike at perusion.com>

Fast, reliable, cheap.  Pick two and we'll talk.  -- unknown