The system allow user groups to map various (weight/mechanical etc) units and screen labels to the database fields - it also allows dynamic generation of input elements for the screen templates. That way, my marketing guys can customize templates and database structure for their clients. Lookups are automatically mapped to fields to come up with select drop-down boxes, multi-select boxes etc.
The system maps the tables and apply all the logic to auto-generate user-customized formatting (of field values), form elements, form validation, SQL Insert and update statements etc.
Note: I am using PHPLib Templates and ADODB for interface abstraction and db abstraction. PHPLib Template engine is very slow so I'm implementing Smarty for the next version.
Example pseudo-struct:
datadict table
- tablename = 'lifting_equipment'
- fieldname = 'loadweight_max'
- datatype = 'double'
- output = 'Wt. (Max)'
groupunits table
- tablename = 'lifting_equipment'
- fieldname = 'loadweight_max'
- unittypeid = 'WEIGHT_LIGHT_KG'
unittype table
- unittypeid = 'WEIGHT_LIGHT_KG'
- valuefrmdb = 'x * 100' //
- valuetodb = 'x / 100'
When the system loads the lifting_equipment table, the system will know the user's preference for units (in this case kilograms) and converts the database value to their value by doing an eval (i know... security issues here) of the formula. Vice versa when the user sends data to be saved. I need this because the client's are multi-national companies and different countries have different unit preferences and they share a common db. I cannot use simple numbers in the valuefrmdb and valuetodb fields because some units are non-linear in nature (ex.: temperature).
Why 2.5mb? We have about 2,000 odd fields in the monster database so 2,000 items of the datadictionary items to load, 180 unit details and about 800 groupunits (mapping the type double fields to their corresponding units), 800 language translation records, etc. Not to mention a varying amount (dependent on client customization) of lookup maps.
Lookup maps are:
lookup:
$this->lookup["rating"] =
array(
"a" => "Good",
"b" => "Fair",
"c" => "Junk"
);
$this->mappings["lifting_equipment"]["rating"] =& $this->lookup["rating"];
When the above mapping is done, when the system generates the screen content, it knows to use the function to generate the appropriate drop down box OR to show the long form of the text instead of the short codes.
With sessions, I wanted to load (and store) all of them at once. As loading all of them fresh would cost me about 300-400msec. However, it takes about 2 seconds or more for PHP to load the fat session file and deserialize it. Very expensive indeed.
I need most if not all of the lookups because of the way the system is set up to allow the system to generate an XML file to be passed to FOP for PDF rendering of a complex user report.
It's a huge overkill, but that's the expense of creating a multi-language, multi-unit, dynamic system. I have another engine in the works that totally change how the system operates by implementing plug-ins where the base class includes various classes which acts as an array of classes - these plugins can vary from the authentication module and lookup module all the way up to the engine that interfaces with Smarty. I still feel that without an SRM in the system could be easilly overloaded so I'm still not having a good night's sleep here.
