About AppWrap - a self-indulgent ``Great American Novel.''
AppWrap is an enterprise content management system with 3 objectives:
AppWrap realizes these objectives by providing a web interface to a relational database, and a clean separation between code and content.
All components of AppWrap are Open Source, as is AppWrap itself.
AppWrap got its start in a small, growing company struggling to produce a decent weekly status report. The process involved users each week sending a template-based MS Word document to the VP, who compiled the inputs into a single MS Word summary for company-wide distribution.
This approach did not scale well. As the company grew it took longer and longer to produce the report each week. Contributors frequently missed the document submission deadline. The process provided no way to flag changes from the previous report, and the resulting report was not easy to adapt for other reports. Useful data from individual inputs was lost during compilation. Senior management often wanted mid-week snapshots of status.
We proposed AppWrap as the solution. The Web front end allowed users to record status as it occurred, and allowed others to view these entries in real time.
The database stored all current data, and retained all changes for tracking purposes. Once all data were being stored in the database it became easy to track historical changes, and to view this history by clicking a hyperlink.
Under the hood we wanted to avoid maintaining a large and ever-growing number of scripts or templates. We also wanted the flexibility to use AppWrap to manage an expanding data set without continual recoding.
After modelling typical user activities we designed AppWrap with 3 core components: user data tables, meta-data tables and generic Apache handlers.
User Data Tables contain the actual data which interests users. Tables are defined in SQL to hold data elements (table ``columns'') agreed between user representatives and an AppWrap developer. Each table includes 3 mandatory columns which make it possible for AppWrap to manage all user data tables identically. These columns are called idnum, email and created_date. Idnum contains a serially increasing integer which makes every record in the table unique and is a consistent table index. Email contains values which uniqulely identify all contributors. (The term ``email'' is probably too specific: other identifiers could adequately serve this purpose, such as a user ID, screen name or MD5 hash, for example.) Created_date is the date the record was first created.
Meta-data Tables contain data about user data. AppWrap has four core tables for it: my_tables, my_columns, my_exceptions and my_defaults. (These tables are described in greater detail elsewhere in the AppWrap documentation. ) Every handler queries meta data to influence the presentation of user data.
There are additional tables which may be called 'meta-data`` tables. Such tables provide lists for pop-up menus (such as is seen in the ''contact type`` field when doing an ''add`` for table ''contacts``) or for filtering data (table ''regions`` allows every country to be associated with an organizational region in the company.'') As these tables are not accessed directly by users and are usually ignored by the administrator after initial creation, we don't give them much attention in these docs.
AppWrap handlers are generic in the sense that they make few assumptions about the composition of the user data requested. Specific information required to accurately present user data is found in the meta-data tables. To improve performance meta-data is cached for each handler's use. This approach allows a single handler to perform it's function on any number of user data tables.
How_AppWrap_Works.pod