GemsTracker is a library that extends the Zend Framework libraries, but also supplies a standard new project template.
GemsTracker supplies a default new_project installation that allows you to quickly setup a standard project. The package contains these directories:
application
Project specific code and settingsclasses
Project specific classesconfigs
Project specific Zend Framework, GemsTracker and database configuration filescontrollers
(Optional) Project specific Zend FW controllersevents
(Optional) Project specific track engine eventslanguages
(Optional) Overrule the default translationslayouts
(Optional) Project specific Zend FW layoutssnippets
(Optional) Project specific code that generates Htmlviews
(Optional) Project specific Zend FW viewshtdocs
The webroot of the projectgems
Default GemsTracker css, images and jQuerylibrary
The location for the GemsTracker library and optionally the Zend FrameWork?Gems
The GemsTracker library directory, link to a stable release or to our development branchvar
A writable directory for files that can change after installationcache
Cache and sessionslogs
Error logssettings
File locks and other installation dependent settingsuploads
Pdf's ant other uploadable filesGemsTracker is implemented as a separate library. You should either link to a stable tagged release and not change the code, or if you are involved in the project you can develop against the GemsTracker trunk.
The directory structure is based on the standard Zend Framework project directory structure with some extensions.
classes
The main project codeconfigs
Database definitions for project typescontrollers
Zend FW Controllers stubs that can be overruled by a projectdocs
Some documentationlanguages
Default translations (currently Dutch and English)layouts
GemsTracker default Zend FW layoutssnippets
Code that generates reuseable Html fragments / snippetsviews
GemsTracker default Zend FW views (but very empty for a Zend project)GemsTracker builds on the Zend Framework but does not follow in slavishly. Some changes are caused by the requirement that standard code can be overruled at the project level. Other changes were made because we want to extend the Zend Framework (but did not yet get round to the extensive documentation and unit testing required by the framework). These two types of extensions are easily distinguished by their parent directories within the classes directory:
Gems
The core of GemsTrackerMUtil
Possible extensions to Zend, should not be Gems specificZFDebug
A Google build debug extension for ZendZend
Those extreme exceptions where we really had to fix a Zend bug (currently only one)GemsEscort.php
The Zend Bootstrap object for GemsTracker. This object handles initialization, layout and security. The GemsEscort? object must be overloaded at the project level.For Gems and MUtil we generated API documentation, but here we will describe their effect on Zend Framework development.
MUtil stand for MagnaFacta? Utilities. MagnaFacta is one of the companies hired to develop GemsTracker.
When a MUtil directory has the same name as an existing Zend directory it usually concerns a simple extension of that Zend component. E.g. the Markup
directory contains an extension that renders e.g. BB or Wiki code to flat text. Always useful if you want to include a text version for smartphone with an HTML e-mail message. The Potemkin Translate
adapter allows you to act as if there is a translator, without defining any.
However some other default extensions are more important:
Application
Extends the Zend Bootstrap
object to an Escort
object that allows .NET like event function use during the whole application request cycle.Controller
Extends the standard Action
to include the use of new Html
, Models
and Snippets
componentsForm
Provided extensions for using both tabbed and tabled forms, improved focus handling and use of the Html
component.Other directories extend the framework. These can be divided in two sets, high-level and low-level. We start with the low level extensions. The low-level do not adapt the Zend Framework, but enable the other extensions:
Lazy
Delayed execution, think callable with parameters and repetitionParser
An SQL parser for SQL script processingRa
Array and parameter processing functionsRegistry
Automated object parameter loading using a registryUtil
Programmer extendable functionality (e.g. for factory functions in Ra, Html and Snippets)The high level packages are the ones that make a GemsTracker a non standard Zend Application:
Html
Simple extendable HTML classes using Lazy
repetition and Ra
parametersModel
The M in Model View Controller. Describe labeling, display formatting, validating, etc… for non-db or db-based data setsSnippets
Quickly create reusable HTML fragments from code. Use of Html
, Model
and Registry
is prepared but not required
Most components in Gems
extend a Zend
or MUtil
component adding functionality specific to GemsTracker, without adding any significant changes to the existing workings of those components. The exceptions fall in two broad categories: those that enable extensions and changes at the project level and those that form the core of GemsTracker.
Default
Standard controllers, for easy overloading of controllers at the project levelLoader
Allow 'mirrored' project level objects to be loaded instead of Gems level objectsProject
Choose multi-layout, multi-organization, logging level and track typesCommunication
(SOAP) communication with external applicationsEvent
Survey or track specific code triggered before or after a survey is takenExport
Data export for scientific analysisMenu
The application menu, of course adaptable at the project levelTracker
THE CORE: integration with survey sources, track engines and token displayUser
Extensible, role based user authentication and authorization