- BUILT-IN FEATURES
- USING AND EXPANDING CSS
- SEE ALSO
share/web/static directory of Jifty, keeping separate
js subdirectories for each of both sets of files. When using Jifty without any interference into these files, all of those files will get loaded from the Jifty-provided directories.
In both cases, there are hooks for expansion by keeping empty but present files in the
js directories. By simply creating and populating these files inside the
share/web/static/js directories brings the predefined hooks to work.
Also there is a big difference of the whole operation between an application running in
DevelMode or a productive application. In DevelMode, every single CSS and JS file will get included into every single template page being rendered. On the other hand, a productive application will merge all CSS and JS definitions upon the first request and will only include one file each containing all CSS and JS definitions in a single request.
USING AND EXPANDING CSS
Assembly of CSS definitions
When Jifty assembles all CSS definitions (which is internally done inside Jifty::Web by the method
include_css), a single file,
main.css is included into the generated HTML code of the current page. This file consists of a series of
@import directives that reference every single CSS file to get used.
Expansion of CSS definitions
Jifty maintains two initially empty files,
app.css that may get "overloaded" by simply providing these files in an application's
These two files will get included in different order,
app-base.css being the very first and
app.css getting included very late in the CSS construction process.
This means that general definitions that should apply to all subsequently encountered styles could easily get done in
app-base.css whereas individual redefinitions, expansions or your application's own definitions could go into
Jifty's own definitions
Jifty provides a series of definitions that are responsible for a good look without any modification. Please note that not all of the used CSS classes are already defined, but they will provide a hook for modification of the general look. Some of the styles are listed below.
- form_errors, error
Error messages encountered during validation are displayed inside a
<div>tag of class
form_errorswhich initially is not yet defined. Every single error message is marked with a class
- hints, warning, error
These classes are used for displaying additional information for form fields.
- form_field, mandatory, argument-$name
Every form field including its label is packed inside a
<div>tag with these classes (mandatory only if the field is mandatory, of course), where
$nameis the field's name.
This section is a
<span>tag filled with a form field's preamble content that could contain additional instructions for the user. The content may be set by the
preambleaccessor method that is available for every
Jifty::Web::Form::Fieldand its successors.
These class names are used depending on the type of widget getting rendered.
used for the autocomplete div.
These classes are used in navigation bars.
- jifty, results, messages
These three CSS classes are used to surround a message block displaying an action's messages after having run an action.
- message, error, $moniker
Every single message that is displayed in an action's result box is marked with the message's type plus the action's moniker as a CSS class name.
Hereby, major support for encoding and decoding data into the JSON data format (similar to
YAML) is provided.
Assembly of JS definitions
Jifty maintains a complete list of JS files to include. This list may be retrieved or set by the accessor
Initially empty; put all JS functions you need to define here.
Reserved for defining behaviors for DOM objects using the
The assembly process of all JS definitions is done in Jifty::Web by the method