updated as of: August 20, 2012
last author: Andy Theuninck
Install-anywhere
IS4C should be able to function without any specific path requirements. For the most part, the AutoLoader class takes care of this. Include that file using a relative path and you should be all set.
Modular Parsing
All parsing is done by two arrays of parser objects. All parser objects have the same base class. Adding and removing them is as simple as dropping a file in the appropriate directory: parser-class-lib/parse or parser-class-lib/preparse. Note that class name and file name should match.
Classes for UI
The classes in gui-class-lib provide a uniform way to do screen output. Using one of these classes makes it easier to create a new "page" that matches the rest of IS4C visually and ensures doctype, css, and js are brought in correctly.
Modular Paycards
The various payment gateways I've worked with have a lot of similarities. Exact implementation can probably be interchangeable as far as the rest of IS4C is concerned. Since sharing the exact implementation for a gateway isn't always permitted, pushing as much as possible into a generic base class ought to streamline the implementation when people are forced to re-invent the details.
Hardware Flexibility
There should be classes to deal with printers, scales, and other peripherals so support for new hardware can be added without revising existing code.
Database Best Practices
This is the hard part. Ideally, we'd all keep the same schema. Realistically, I don't see this happening. With a little caution, I think we can at least have scripts that degrade gracefully when the underlying structure changes. Ideas:
- Grab row values by column name instead of numeric index. As long as the column exists, you'll get the right value, regardless of actual layout
- Use the SQLManager class where you can. I know most people are using MySQL, but I don't see any downside to keeping the system fairly open. If someone wants to run IS4C on top of Postgres, it's a much easier port down the line. There are also a couple bits of handy functionality:
- SQLManager::smart_insert(table_name,value_array) - this method takes an array of column names & values, polls the given table to see which of those columns are available, then forms an appropriate INSERT statement. Obviously this doesn't guarantee all your information will be written, but it increases the chances of basic success. If your script is trying to create a products record, it'll probably at least get a row into that table with upc, price, department, etc.
- SQLManager::smart_update(table_name,value_array,where_clause) - coming soon!
- Put CREATE statements in install script when you need new tables. This makes it easy for other developers (and regular users) to add the tables your script needs. Don't drop and recreate tables that already exist; deleting someone else's data is impolite.