SiteMap
Page Bottom  Documentation

Templates,prototypes,stds & instances

"Phoenix" is a general purpose user interface that has been put to use for ProCash to help in "Real Estate Investment Analysis where value is primarily created thru leases". "Phoenix", as implemented for ProCash, makes possible the creation of templates which help make analysis of new projects easy. Many templates are available, and new templates are easily created, so a wide variety of projects can be well served.

The term "templates" has many possible meanings. We'll use that term in marketing (and maybe even in help files), but more precise language is needed for technical documentation. This note will help in providing that technical detail. (updated 6/14/08 16:25)

Let's coin the term "Phoenix instances". They provide the data shapes & the lL and lC vars required by views so, \views\ never change, they are simply augmented by one or another set of "Phoenix instances". We are working with 3 Phoenix instances at present which assume use of the Low Income Housing Tax Credit (LIHTC). These Phoenix instances are compiled from actual project data which is identified as "qkID" (TNA,‘id[3]):

fhfcb 14 12 Tower Point Apartments (simple use of inputs)
fhfcd 14 13 Tower Point Apartments (detailed inputs)
bhbii 3 91 BHP II Limited Partnership (even more detailed as development gets underway)
Phoenix instances where M's only have default values are the start of any Phoenix aided project. These might be called "starter files" and might have names like: 'fhfcb.sf' 'fhfcd.sf' 'bhbii.sf'. They will be stored in the \projects\ folder along with all (input,output) data from all project data which is managed by the Phoenix system. Any existing ProCash project (input,output) file is just as good as a starting point for any new project. When a new Phoenix instance is needed, a skilled person will create a prototype outside of Phoenix. The function "CreateViews" (perhaps renamed to "CreatePhoenixInstance") will then create a Phoenix instance from the prototype

A "set of standard assumptions" and "a set of raw data" and "a set of null (unusable) data" and "an example project" and "a finished project" and "a partial project in work" and "variations on a single project" and "a composite project" perhaps should all be indistinguishable from one another (except for the actual numbers and the file name that a human would use to tell them apart).

Projects have real data, like rent rates and cost per square foot and interest rates. A raw Phoenix instance usually won't have those. But a client could want a variation whereby a bunch of "standard" assumptions were built into the "instance", then it would not be a "raw instance", but it would be a "set of standard assumptions". An example of this could be the "boilerplate 3 story walkup garden apartments "we" build with First Equitable financing". Then that client might only have to change a dozen assumptions for local conditions while keeping dozens of assumptions standard. Then, of course, we need an "exceptions report" whereby the client can compare the Savannah project with his standard assumptions.

If one does not like the term "Phoenix instance", we could do just as well by calling it the (or a) "project file". Project files are stored in the \projects\ folder, and there is no other type of file in that folder. A "view file" is stored in the \views\ folder and there is no other type of file stored in that folder.

When loading a project file, we should automatically close all view windows and disable the view menu until we can tell what views are applicable to the newly-loaded file.

horizontal line
to home page e-mail Page Top