updated as of: August 20, 2012
last author: Andy Theuninck


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: