NAME¶
Jifty::Manual::Glossary - The Jifty dictionary
GLOSSARY¶
We use words. This is what they mean.
  - action
 
  - An action is a specifically designed RPC call that
      can do something to the system, with any number of declared
      "parameter"s. At runtime, an action can take
      "argument"s, which it "canonicalize"s,
      "validate"s, and then uses to do something useful. Each action
      has a "result". See Jifty::Action and
    Jifty::Manual::Actions.
 
  - active
 
  - For an "action" to run, it needs to be
      active. Most of the time, all actions submitted are active, but it
      is possible to specify only a specific action as active; any non-active
      actions are ignored. See Jifty::Request.
 
  - AJAX
 
  - An acronym standing for Asynchronous Javascript And
      XML. Though technically incorrect, it is the buzzword that describes
      doing asynchronous requests to the server while the user waits. This can
      lead to very "dynamic" pages, as the browser does not need to
      refresh the entire page to update a small section of the screen. In Jifty,
      the sections of the screen are called "region"s. See
      Jifty::Web::PageRegion.
 
  - argument
 
  - An argument is a user-supplied input to fill in a
      "parameter" in an "action". See Jifty::Action.
 
  - canonicalize
 
  - To turn an "argument" into a more standard form.
      For instance, a canonicalizer could translate a user-typed date into a
      date object or a SQL-formatted date string. See Jifty::Action.
 
  - collection
 
  - A /collection is a class representing all or a
      subset of the records stored in the database regarding a particular
      "model". See Jifty::Collection.
 
  - constructor
 
  - A property of a "parameter"; the action
      must have an argument value for this parameter in order to be
      constructed. This is different from "mandatory", in that the
      user can leave mandatory fields empty. For instance, the "id" of
      a Jifty::Action::Record::Update is a constructor. See Jifty::Action.
 
  - continuation
 
  - A concept stolen from Lisp, Scheme, Smalltalk, and Perl 6.
      The continuation of any particular piece of code is the deferred
      operations that care about the return value at that point. In the context
      of Jifty, a continuation is a deferred "request" that may pull
      "argument"s and the like from the "result"s of the
      current request. Continuations can be arbitrarily nested, so they are
      often useful to keep track of tangents that the user went on. See
      Jifty::Continuation.
 
  - database version
 
  - The database version is the "schema
      version" last installed or updated in the application's database. In
      general, the database version will always match the schema version. The
      exception is when Jifty is updated to a new schema version, your
      application updates to a new schema version, or a plugin updates to a new
      schema version. When this happens, you must "update" your
      database so that the database versions and schema versions match before
      running your application.
 
  - form field
 
  - A widget which the browser renders. These are generally
      useful to ask the user for a value for an "argument" to an
      "action". See Jifty::Web::Form::Field.
 
  - fragment
 
  - A section of HTML (at present, a Mason component) contained
      in a "region". Fragments are a kind of standalone Mason
      component which the browser can request individually. Because of this,
      they can only take strings and scalars as arguments, not references or
      objects!
 
  - element
 
  - A Mason component used by one or more other pages, which is
      not a whole page of itself. As opposed to fragments "elements"
      are strictly internal, and never visible to the outside world by
      themselves. Elements typically live under a path beginning with or
      containing '/_elements'. This, and the whole idea of an element is
      strictly convention, but Jifty contains elements for things like page
      headers, menus, and showing keybindings out of the box to make your life
      easier.
 
  - mandatory
 
  - A property of a "parameter"; the user must enter
      a value for the action to validate. This is the simplest level of
      validation.
 
  - model
 
  - Jifty uses Jifty::DBI to store its data (though might use
      other storage tools at some later time). The model defines the
      "schema" and provides a package for creating, reading, updating,
      and deleting records stored in the database. The model is generally a
      subclass of Jifty::Record. Access multiple items from a model is performed
      through a "collection".
 
  - moniker
 
  - Every instance of a Jifty::Action has a moniker.
      Monikers serve as identifiers for actions, to associate arguments with
      actions and to access specific actions "by name". Monikers need
      not be globally unique, but they must be unique within a single request.
      Monikers have no semantic meaning. See "monikers" in
      Jifty::Action
    
 
    A moniker is an arbitrary-length nonempty string containing no semicolons.
      It may not begin with a digit. 
  - parameter
 
  - A parameter is a named parameter to an
      "action". Jifty generally renders these on the screen as
      "form field"s. See Jifty::Param and Jifty::Param::Schema.
 
  - region
 
  - An area of the page which JavaScript can replace. The
      content in the region is a "fragment". Think of the region as
      the box and the fragment as the content in the box. See
    Jifty::PageRegion.
 
  - request
 
  - A single query which lists "action"s to run,
      together with a page or list of "fragment"s to return. This most
      often comes from the browser as query parameters, but may come from other
      sources as a JSON or YAML POST request. The answer to a request is a
      "response". See Jifty::Request.
 
  - response
 
  - The answer to a "request", it contains a
      "result" for every action that ran. See Jifty::Response.
 
  - result
 
  - The answer to a "action", it contains information
      about if the action was a success or failure, and further detail about why
      or how. It can also contain arbitrary "content". See
      Jifty::Result.
 
  - return
 
  - After performing a "tangent" a user may perform a
      "return" to invoke the "continuation" created by the
      original tangent.
 
  - schema
 
  - The schema for a "model" represents the
      structure of the data stored in an individual item in that model's
      "collection". See Jifty::DBI::Schema.
 
  - schema version
 
  - The schema version is a number in version object
      used to determine which "database version" your application code
      is expecting to use. There are three places where the schema version is
      important:
 
  - 1.
 
  - Jifty application version. The Jifty application
      stores some details in the database.
 
  - 2.
 
  - Your database version. Your application keeps a
      database version recorded in the configuration. See Jifty::Config.
 
  - 3.
 
  - Plugin versions. Each plugin has a version
      associated with it affecting whatever "/model"s it uses.
 
 
 
If any of these versions differs from their respective "database
  version"s, then you need to run the Jifty::Script::Schema to
  "upgrade" to the latest schema version.
 
Contrast with "database version".
 
  - sticky
 
  - A property of "form field"s. If a field is
      "sticky," values that the user entered appear there again when
      the page is rendered again, avoiding making the user type them again. Most
      "action"s have form fields which are sticky on failure, so the
      user can update the information and try again.
 
  - tangent
 
  - A tangent is a link or redirect that causes Jifty to save
      the current state into a "continuation" for a later
      "return". This operation is handy for situations when you want
      to jump to another page or form, but return to this page when the user is
      done with the "tangent" page. Because of the use of
      continuations, this can be especially handy because a user could go on
      multiple tangents and eventually return to the start.
 
  - upgrade
 
  - Generally, your Jifty application will change over time.
      Most of these changes will be simple changes to behavior or appearance.
      When changes are made to the "schema" structure of your
      database, you may need to perform an upgrade. An upgrade is
      the process by which you rename columns, initialize data, or otherwise
      update information that needs to be updated when a change to the database
      needs to be made. See Jifty::Upgrade, Jifty::Manual::Upgrading, and
      Jifty::Script::Schema.
 
  - validate
 
  - To check that the provided value of an "argument"
      is a possible value for it to have. See Jifty::Web::Form::Field.