module Tempo
The Base model class, from which all other models are derived. Models are given a unique id, which is stored in the class index. FileRecord
handles all file storage and retrieval. Options are passed through to FileRecord
for the purpose of sending in an alternative directory. example: options = {directory: “my_directory”} will save to Users/username/my_directory.
Composite Model
extends base to accomodate tree structures Each instance can be a root instance, or a child of another instance, and each instance can have any number of children. report_trees is a utility method for testing the validity of the model, and can be used as a template for creating tree reports.
Log extends base by allowing models to be associated with a time instance. Ids are only unique by day, and each model also has a day id. Together these two ids assure uniquness. When saved, each day is recorded as it's own file.
Time
Record is an extension of the Log Model
, it adds an end time, and verifies that no records overlap in their time periods. Additionally, one, and only on record can be running at any given time, and it can only be the most recent record.
Tempo
View Formatters are triggered by the View Reporter. The View Reporter sends it's stored view messages to each of it's formatters. It calls the method format_records and passes in the view records. If the formatter has a class method that handles the type of block passed in, it will process that view record. These class methods take the name “<record type>_block” where record type can be any child class of ViewRecord::Base see the screen formatter for an example of processing blocks.
The Console block handles interactive queries and progress reports. It is required when reporting must be done in 'real time' rather than compiled during runtime and then presented at the end (see Views::Screen). It is the only formatter that receives blocks as soon as they are handed to the Reporter
Tempo
View Formatters are triggered by the View Reporter, and all inherit from Views::Base
The screen formatter is the primary formatter for reporting results back to the screen. All formatting is handled after the main processes, when the Reporter is invoked during the post block. (If immediate feedback is needed, see Formatters::Console)
The Views
Reporter is responsible for presenting all the views using the specified formatters. The Reporter is initialized in the GLI pre block, where all additional formats are added. The reporter executes the reports during the post block, displaying all views that have been added by the views.
class instance variables:
@@console
A shell formtter which receives view records as they are created and can intercept messages that should be displayed in real time, as well as interactive prompts
@@formats
an array of formatters, which will be passed the view records on exit Reporter will always run the error formater first, to check for errors in the view reports, followed by all added formatters, and then finally the screen formatter. This allows additional formatters to add view records, which will be presented on screen.
@@view_records
add view_records
ViewRecords are simplified models, with additional display information, used in views.
Each viewrecord has a :type, which can be queried in the view to know what type of record it is managing.
They also each have a format method, which accept a block, and also includes a default block which returns a basic formatted string.
ViewRecords can be nested, for instance the Time
ViewRecords contain a Duration ViewRecord.
View records should add themselves to the Reporter on init, with the exception of partials (such as duration), which are managed within other view records
They have no logic, and so it is up to the creation method to make sure they are a correct copy of the information they are representing.
@pre = Optional record which is sent to the formatter before the collection @post = Optionsal record which is sent to the formatter after the collection
Constants
- VERSION