We use words. This is what they mean.


An action is a specifically designed RPC call that can do something to the system. An action takes any number of "argument"s, which it "canonicalize"s, "validate"s, and then uses to do something useful. Each action has a "result". See Jifty::Action.


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.


An acronym standing for Asynchronous XML And Javascript. 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.


An argument is a named parameter to an "action". Jifty generally renderes these on the screen as "form field"s. See Jifty::Action.


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.


A property of an "argument"; the action must have a value submitted for this argument 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.


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.

form field

A widget which the browser renders. These are generally useful to ask the user for a value for a "argument" to an "action". See Jifty::Web::Form::Field.


A section of HTML 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!


A property of an "argument"; the user must enter a value for the action to validate. This is the simplest level of validation.


Every instance of a Jifty::Action has a moniker. A moniker is an arbitrary-length nonempty string containing no semicolons. Monikers need not be globally unique, but they must be unique within a single request. Monikers have no semantic meaning.


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.


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.


The answer to a "request", it contains a "result" for every action that ran. See Jifty::Response.


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.


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.


To check that the provided value of a "argument" is a possible value for it to have. See Jifty::Web::Form::Field.