DB Editors, new const values, and package dimensions

This message was sent from: Suggestions and Proposals
http://forums.oscommerce.com/viewtopic.php?p=187449#187449
----------------------------------------------------------------

Is anyone aware of ongoing work to develop a simple table editor for managing constants (configuration values)? I found a bunch of obvious constants that were missing from the default install.

As a developer of new contributions, I would impore the core team to consider either:

a) A database table editor (allows one to add/edit simple constants) from the configuration screens, to allow non-programmers to more comfortably extend their database tables/values.
b) Extend the list of existing constants to include more logical combinations(Create a suggestion thread)

For example,

I was writing a new shipping module and discovered that 2.2MS1 has the following default configuration values:

STORE_NAME and STORE_NAME_ADDRESS
but not STORE_ADDRESS

This makes it more difficult to print invoices where the store name text is larger than the store address, or where you simply want the store address without the name. STORE_NAME_ADDRESS should become STORE_ADDRESS, and all references to STORE_NAME_ADDRESS should change to STORE_NAME + STORE_ADDRESS. During install, keep the old constant with an additional insert to prevent breakage:

insert (STORE_NAME, $runtime_install_user_defined_store_name);
insert (STORE_ADDRESS, $runtime_install_user_defined_store_address);
insert (STORE_NAME_ADDRESS, STORE_NAME . STORE_ADDRESS);


Next...

STORE_ZONE and STORE_COUNTRY
but not STORE_ZIP.

I don't particularly care about this one, but shouldn't these constants be available should a store owner decide to use them? Better yet, why not create a set of constants such as:

STORE_NAME, STORE_ADDRESS_1, STORE_ADDRESS_2, STORE_CITY, STORE_ZONE, STORE_COUNTRY, STORE_ZIP, STORE_PHONE, STORE_FAX, STORE_EMAIL

STORE_FULL_PARTICULARS = (all of the above)
STORE_ADDRESS = (the latter parts of the above)
etc.


Another...

STORE_ORIGIN_COUNTRY and STORE_ORIGIN_ZIP
but not STORE_ORIGIN_ZONE

This is where I personally ran into the problem. The UPS XML module I wrote is very particular about shipper addresses when they originate from Canada. In particular, they require state/province to be specified otherwise they have no idea how to handle the request.

Where this becomes a problem is when distributing the new shipping module. It's much nicer to drop in a pair of module class and module language files than to require each store owner modify his/her database to support constants.

My shipping module could likewise just as easily have derived the shipping origin zone, country, and zip from STORE_ZONE, STORE_ORIGIN_COUNTRY, and STORE_ORIGIN_ZIP respectively, but the first requires a lookup to get the zone name from the zone code, and it's just not clean.


Finally,

The database supports values for package sizes, but the products themselves have no dimensions. While you can pass the package size to the shipping modules, there is no way to determine how many products fit into one box. Why, if I'm ordering 3 CDs, would I package them all separately when if they're all packaged together I can save the customer 200% on the shipping costs?

I personally have opted to extend the idea from Tom Croix's (Canada Post 3.1 Shipping Module) to support package dimensions with intelligent packaging. Ideally, products will have Length, Width, Height, and a fitting multiplier (how well the product packs up - you might only fit one umbrella in a huge box, but there might still be room for several pairs of galoshes) and the fitting algorithm will attempt to "best fit" the packages so as to reduce the total number of boxes required. All of this is to increase the accuracy of shipment costs, which results in a simply better shopping cart system.


Thanks for hearing my 2 cents worth.


Torin...