Moodle APIs 4.3
Moodle 4.3.6 (Build: 20240812)
|
Abstract class for blog_filter objects. More...
Public Member Functions | |
__construct ($id, $type=null) | |
Static Public Member Functions | |
static | get_instance ($id, $type) |
TODO This is poor design. | |
Public Attributes | |
array | $availabletypes = array() |
An array of strings representing the available filter types for each blog_filter. | |
array | $conditions = array() |
An array of WHERE conditions $conditions. | |
int | $id |
The unique ID for a filter's associated record $id. | |
$overrides = array() | |
An array of filter types which this particular filter type overrides: their conditions will not be evaluated. | |
array | $params = array() |
An array of SQL params $params. | |
array | $tables = array() |
An array of table aliases that are used in the WHERE conditions $tables. | |
string | $type |
The type of filter (for example, types of blog_filter_context are site, course and module) $type. | |
Abstract class for blog_filter objects.
A set of core filters are implemented here. To write new filters, you need to subclass blog_filter and give it the name of the type you want (for example, blog_filter_entry). The blog_filter abstract class will automatically use it when the filter is added to the URL. The first parameter of the constructor is the ID of your filter, but it can be a string or have any other meaning you wish it to have. The second parameter is called $type and is used as a sub-type for filters that have a very similar implementation (see blog_filter_context for an example)
blog_filter::__construct | ( | $id, | |
$type = null ) |
Reimplemented in blog_filter_context, and blog_filter_user.
|
static |
TODO This is poor design.
A parent class should not know anything about its children. The default case helps to resolve this design issue
array blog_filter::$availabletypes = array() |
An array of strings representing the available filter types for each blog_filter.
$availabletypes