|
|
| (24 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| Using parameters with a component
| |
|
| |
|
| Background
| |
| One thing that sets Joomla! components apart from other types of Extension (i.e. modules and plugins) is the ability to store data in the Joomla! MySQL database. Typically, this data will be content for displaying on a page (such as the content of an article, or its title) or data about how that content should be displayed (e.g. a setting specifying whether or not the title should be shown). A component normally creates at least one table in the database to store this data - for example, data for articles (associated with the com_content component) are stored in the <code>jos_content</code> table (where ''jos'' is the table prefix for the site).
| |
|
| |
| However, choosing exactly where to store each item of data requires a little more thought. There are essentially two choices: each data item may be stored in its own field, or a collection of data items may be stored within a single parameters field. (Of course, there is nothing to stop you making use of both methods, for different data items, within the same component). Which approach you use for a given data item is largely a matter of personal choice, although there are some factors to consider:
| |
| * Core code included in the Joomla! installation makes it very easy to produce the appropriate form elements for entering data into '''parameters''' in the backend. If you choose to save the data in separate fields, you will need to code the appropriate form elements yourself.
| |
| * Again, Joomla! core code allows you to set default values for '''parameters''' across the whole component. Individual component items (e.g. individual articles) can then choose to use the default values, or to override them with values specific to that item. See below for details of how to do this.
| |
| * It is not possible to extract individual parameter values directly from the database. Instead, the whole parameters field must be extracted and parsed to obtain the different parameter values. This means that it is not very easy, for example, to run MySQL queries that search for a parameter with a particular value. Any data that you want to run queries against should be given its '''own table field'''.
| |
| * Similarly, it is not possible to run data validation on parameter fields before saving data.
| |
| In general, parameters are conventionally used to store data relating to the ''presentation'' of information. The information itself is generally stored in '''separate fields'''.
| |
|
| |
| Types of component parameter
| |
|
| |
| 1. Component-wide default parameters
| |
|
| |
| These parameters are set once for the whole component, and are generally used to provide the 'default' parameter settings for the component on that particular site.
| |
|
| |
| 2. Menu item specific parameters
| |
|
| |
| A menu link to an individual component item (e.g. an article) can also have parameters associated with it, which can affect the way the component item is displayed ''using that link''. The types of parameters available will depend on the way that the component item is displayed (the 'view' in MVC terms, but don't worry if this doesn't mean anything to you!). However, the precise values of those parameters can be set for each menu link individually. If there is another menu link to that same component item, then it is important to realise each menu link may have different parameter values, and so the same article may be displayed differently in the two cases.
| |
|
| |
| A menu link can also override the component-wide default parameters, so that the override values (if set) are used in place of the default values ''for that component item when accessed via that menu link''. As you would expect, when no override value is set, the default value is used instead, in the normal manner.
| |
|
| |
| 3. 'Article' specific parameters
| |
|
| |
| Finally, each component item (e.g. article) can have parameters which apply to that item, regardless of how it is accessed (i.e. via any available menu link, or even without reference to a menu at all!). If the component designer wants, the article specific parameters can also be set up to use the 'override' behaviour, so that they default to the current values of the corresponding component-wide parameters, though this is not essential. Again, this is described further below.
| |
|
| |
| Storing the parameters and their values.
| |
|
| |
| In general, a set of parameters is stored within the database in a single <code>text</code> field. Different parameters are separated by <code>newline</code> characters ('/n' in MySQL - each parameter will appear on a different line when you look at the data in something like phpMyAdmin). Each parameter consists of the parameter name and value, separated by an equals sign (=).
| |
|
| |
| <source>
| |
| parameter1=parameter1value
| |
| parameter2=
| |
| parameter3=parameter3value
| |
| parameter4=parameter4value
| |
| </source>
| |