• Config: Houses the configuration information for your app and its systems and subsystems. Provides configuration parameters and knows where to find files.
  
• Ecosystem: Contains all of the environemnt "superglobals"; _GET, _POST ...
  
• Locale: Handles localizing your dates, times, currencies, etc. Also works with Config to find your dictionaries for translations.
  
• OutputGenerator: Parses templates
  
• Perm: Provides centralized location for determining permissions based on User, Ecosystem, and Config information. Meant to be customized for your own needs, contains very little Knickers-level functionality.
  
• User: Handles basic user functionality, including logins and sessions. May be used as-is, or customized to fit your particular needs.
  

• Page: Pretty much just like a Panel, but has the added ability to add a child Page or Panel to itself based on the URL. The idea is that Pages are directly accessible from a URL whereas Panels are contained within pages. An example of a Page would be your user account creation page.
  
• Controller Object: The main object that does all the work that all of your Pages need. Can instantiate a Page based on the URL, sets up the Ecosystem, User, Locale, Perm, OG, and Config objects, runs your Page, and displays the output.
  
• Storage: Collection of objects that handles interfacing with underlying storage. May involve database calls, XML file handling, array storage, etc.
  
• Thing: Usually representative of one record in Storage. Contains the business logic for working with your record and handles pulling it from and storing it to storage.
  
• DataSet: A combination of Things and other DataSets. Handles relationships and aggregate fields.
  
• ComponentFinder: Deals with the interface between your Thing and the user. Handles finding Components for your fields, generating Selectors, and convenient tag grouping in Views.
  
• Component: Handles the user interface for a field. Controls input, data display and, error messages.
  
• Field: Standardized objects for dealing with certain data types. Handle type-level validation and conversions. May be customized for your own use.
  
• Parcel: Package for passing around one or more values. Includes children of Field and FieldSet. May be internally validated and turned into a Component.
  
• Filter: Object for passing around information used for filtering data from storage. Contains a field name, operator, and comparison value.
  
• FilterSet: Method for combining many filters. Allows for filters to be ANDed or ORed together.
  
• Sort: Object for passing around information about sorting data from storage. Contains a field name and a sorting direction.
  
• SortSet: Method for combining many Sorts. Sorts will be combined in the order in which they are added.
  
• Test Case: Class that tests another class. Made up of one or more test methods that test specific class functionality.
  
• ComponentFinderDataProvider: An object that provides data to a ComponentFinder. Always a Getable. Includes classes like Thing, SearchResult, Searchable, and DataSet.
  
• Searchable: Type of Getable that provides searching capabilities and returns SearchResults. Includes DataSet.
  
• Descendable: Type of object that contains children similar to itself that can be 'descended.' Includes data that comes back from Ecosystem and is passed to ComponentFinders on read().
  

• Component: Contains classes for your Components and ComponentFinders.
  
• Controller: Contains your Pages and Panels.
  
• Modeling: Contains your data models. This includes Fields, Things, DataSets, and any custom CFDPs you may wish to create.
  
• dicts: Contains dictionary files and locale configuration files.
  
• tpl: Contains template files for output.
  
• testcases: For storing Test Cases. Directory structure should mirror that of your common and custom directories so that the tester can find your Test Cases based on the class(es) you give it to test.
  

• Panel: A class that has a template and has basic init/isAvailable/run functionality. May contain and be contained by other Panels and Pages. An example of this might be a login form that you want to place on multiple pages
  
• Page: Pretty much just like a Panel, but has the added ability to add a child Page or Panel to itself based on the URL. The idea is that Pages are directly accessible from a URL whereas Panels are contained within pages. An example of a Page would be your user account creation page.
  
• Controller Object: The main object that does all the work that all of your Pages need. Can instantiate a Page based on the URL, sets up the Ecosystem, User, Locale, Perm, OG, and Config objects, runs your Page, and displays the output.
  
• Controller Script: A runnable script that you put into your common directory that instantiates a Controller and sets it going.
  
• VEC: Short for View/Edit/Create. A type of page that lets you do one of the above (or delete) to a record.
  
• SFS: Short for Search/Filter/Sort. Allows you to do any of the above on a set of records.
  

• Label: Translatable string. A single word, without formatting, that is designed to lend consistency to the system and minimize the need to translate commonly-used words.
  
• Message: Translatable, "code generated" string. May have additional values parsed into it. Shared throughout the system.
  
• Template Text: Translatable string, contained within templates and connected to a particular page or Component Template Text is specific to the template it's contained within but is shared across different formats of the same template.
  

email

password