$models
$models :
Advanced controller.
Provides far more functionality than the Basic controller. Including:
You should define "page.default", "page.login" and "layout.default" options in your Nano object.
$resources :
Resources represent external files, such as scripts, stylesheets, etc.
They are managed through a generic system that allows for easy future expansion.
Each group as a resource id, such as 'js', 'css', etc, and the following definitions:
name: The variable name for templates. path: An array of paths to look for resource files in. exts: An array of extensions to look for resource files. groups: An array of arrays, each being named groups. It is recommended to prefix groups with an identifier such as '#'. We include '#common' and '#webapp' as example groups, they depend upon the Nano.js library set. added: An empty array, will be populated by use_resource();
A group for one resource type MAY in fact depend on a resource of another type. For instance, you may have a Javascript file that depends on a CSS stylesheet being loaded. You can define a rule that will include it, by using a 'type:name' format, such as 'css:foobar'.
get_models_with_type( $type, $opts = array())
Return a list of models that are decended from a type, no matter how deep in the group hierarchy they are. Also returns the expanded model options (as returned by get_model_opts() with @types enabled.)
[ 'modelname' => $extended_model_opts, // more here ]
| $type | ||
| $opts |
add_json( $name, $data)
An easy way to add JSON data to the templates.
In your layout, you should have a section that looks like:
<?php if (isset($json) && count($json) > 0) foreach ($json as $json_name => $json_data) echo $html->json($json_name, $json_data); ?>
The above assumes you're using the Messages trait, which should be loaded after this one, and includes the $html template helper. You could also choose to build the JSON fields manually, but the helper is simpler.
| $name | ||
| $data |
__construct( $opts = array())
Provide a default __construct() method that can chain a bunch of constructors together.
The list of constructors that will be called, and in what order, is dependent on the existence of a class property called $constructors. If the property exists, and is an array, then it is a list of keys, which expect a method called _construct{$key}_controller() is defined in your class (likely via trait composing.)
If the property does not exist, then we will get a list of all methods matching _construct{word}_controller() and will call them all in whatever order they were defined in.
| $opts |
send_html(String $screen, Array $data = Null)
Sometimes we don't want to display a primary screen with a layout, but instead a sub-screen, with no layout, and using specified data.
| String | $screen | The name of the screen view to use. |
| Array | $data | (Optional) Variables to send to the screen view. The $data defines the variables that will be made available to the screen view template. If you do not specify a $data array, then the $this->data class member will be used instead. |
send_json(Mixed $data, Mixed $opts = array())
Sometimes we want to send JSON data instead of a template.
| Mixed | $data | The data to send (see below) |
| Mixed | $opts | Options, see below. If the $data is a PHP Array, then it will be processed using the json_encode() function. In this case, there is one recognized option (which is only applicable with PHP 5.4 or higher) 'fancy' If set to True, we will use human readable formatting on the JSON string (aka Pretty Printing.) If the $data is an Object, then it must have a method as per the $this->to_json_method (default: 'to_json'), which will be called, and passed the $opts as its first parameter. If the $data is a string, it will be assumed to be a valid JSON string, and will be sent as is. Anything else will fail and throw an Exception. |
send_xml(Mixed $data, Mixed $opts = Null)
Sometimes we want to send XML data instead of a template.
| Mixed | $data | The data to send (see below) |
| Mixed | $opts | Options, used in some cases (see below) If $data is a string, we assume it's valid XML and pass it through. If $data is a SimpleXML Element, DOMDocument or DOMElement, we use the native calls of those libraries to convert it to an XML string. One caveat: we assume that DOMElement objects have an ownerDocument, and if they don't, this method will fail. If the $data is another kind of object, and has a method as per the $this->to_xml_method (default: 'to_xml') then it will be called with the $opts as its first parameter. Anything else will throw an Exception. |
model(Mixed $modelname = Null, Array $modelopts = array(), Array $loadopts = array())
Return the requested Model object.
| Mixed | $modelname | If set, must be a string, see below. |
| Array | $modelopts | Options to pass to model, see below. |
| Array | $loadopts | Options specific to this, see below. If the $model is not specified or is Null, then we assume the model has the same basename as the current controller. The $modelopts will be added to the parameters used in the class loader (which will in turn be passed to the constructor of the Model class.) If the specified $model has been loaded already by this controller, by default we will return the cached copy, ignoring any new options. The two $loadopts options we support are: 'forceNew' If set to True, we will always create a new instance of the model, even if we've loaded it before. If caching is on, it will override the previously loaded instance. 'noCache' If set to true, we will not cache the model instance loaded by this call. |
get_model_opts( $model, Array $opts = array(), Array $behavior = array())
Get model options from our $this->model_opts definitions.
| $model | ||
| Array | $opts | Current/overridden options. |
| Array | $behavior | See below If the $behavior['defaults'] is True, and we cannot find a set of options for the specified model, then we will look for a set of options called '.default' and use that instead. A special option called '.type' allows for nesting option defintions. If set in any level, an option group with the name of the '.type' will be looked up, and any options in its definition will be added (if they don't already exist.) Groups may have their own '.type' option, allowing for multiple levels of nesting. If $behavior['types'] is True, we build a list of all nested groups. The '.type' rule MUST NOT start with a dot. The group definition MUST start with a dot. The dot will be assumed on all groups. So if a '.type' option is set to 'common', then a group called '.common' will be inherited from. |
addWrapper(String $method, String $varname = Null, Bool $closure = False)
Add a wrapper to a controller method that you can call from a view template (as a Callable.)
| String | $method | The method we want to wrap into a closure. |
| String | $varname | (Optional) The name of the callable for the views. |
| Bool | $closure | (Default False) If true, use a closure. If $varname is not specified, it will be the same as the $method. As an example, a call of $this->addWrapper('url'); will create a callable called $url, that when called, will make a call to $this->url() with the specified parameters. |