mirror of
https://github.com/opnsense/docs.git
synced 2026-05-28 04:02:12 -04:00
docs: Fix typo (#604)
This commit is contained in:
parent
4e4d5f1757
commit
cf5ca27100
5 changed files with 20 additions and 20 deletions
|
|
@ -62,5 +62,5 @@ attributes to the menu objects created there are setters in
|
|||
OPNsense\\Base\\Menu\\MenuItem, in this version the next attributes are supported:
|
||||
|
||||
- order, sort order in our menu
|
||||
- VisibleName, name to use ( if not set the tagname / id will be used)
|
||||
- VisibleName, name to use (if not set the tagname / id will be used)
|
||||
- cssClass, style attributes for the frontend system.
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ When designers need forms for users to input data, they can use the :code:`getFo
|
|||
to feed a simple xml file as definition for the template engine to use. The example section contains a step by step
|
||||
guide how to use these.
|
||||
|
||||
The getForm() method itself merily passes the structure to thew view, which can use this information to render
|
||||
The :code:`getForm()` method itself merely passes the structure to the view, which can use this information to render
|
||||
forms on page load (statically).
|
||||
In our standard layout `partials <https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/views/layout_partials/form_input_tr.volt>`__ we offer some different record types which we will detail below:
|
||||
|
||||
|
|
@ -132,7 +132,7 @@ A simple index controller to echo a request back looks like this:
|
|||
$message = " " ;
|
||||
}
|
||||
|
||||
return array("message" => $message);
|
||||
return ["message" => $message];
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -217,7 +217,7 @@ In order to export or import csv structured data, some helpers are available to
|
|||
The :code:`ApiControllerBase` adds a simple recordset export method (:code:`exportCsv()`)
|
||||
and :code:`ApiMutableModelControllerBase` contains a method to import data (:code:`importCsv()`).
|
||||
|
||||
When data is being exported from a model using an :code:`ArrayField` type, the :code`asRecordSet()` method can be used
|
||||
When data is being exported from a model using an :code:`ArrayField` type, the :code:`asRecordSet()` method can be used
|
||||
to extract the data easily.
|
||||
|
||||
The smallest functional example to download a file from a controller implemented with :code:`ApiMutableModelControllerBase`
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ Check if hostnames are valid, includes the following options:
|
|||
IntegerField
|
||||
------------------------------------
|
||||
|
||||
Validate if the input contains an integere value, optionally constrained by minimum and maximum values.
|
||||
Validate if the input contains an integer value, optionally constrained by minimum and maximum values.
|
||||
|
||||
.. csv-table:: EmailField
|
||||
:header: "Parameter", "Options", "Purpose"
|
||||
|
|
@ -526,7 +526,7 @@ generates :code:`<optgroup>` clauses in our model. As of 24.1 they can be defin
|
|||
PortField
|
||||
------------------------------------
|
||||
|
||||
Check if the input contains a valid portnumber or (optionally) predefined service name. Can be a range when
|
||||
Check if the input contains a valid port number or (optionally) predefined service name. Can be a range when
|
||||
:code:`EnableRanges` is set to :code:`Y`.
|
||||
|
||||
|
||||
|
|
@ -540,7 +540,7 @@ Check if the input contains a valid portnumber or (optionally) predefined servic
|
|||
"BlankDesc", ":code:`text`", "Set a label for the empty option"
|
||||
"Multiple", "Y,N", "Allow to select multiple options, when set the type is treated as a list"
|
||||
"EnableWellKnown", "Y,N", "Allow the usage of well known names such as 'http' and 'ssh'"
|
||||
"EnableRanges", "Y,N", "Allow the usa of ranges, such as :code:`80:100`"
|
||||
"EnableRanges", "Y,N", "Allow the usage of ranges, such as :code:`80:100`"
|
||||
|
||||
|
||||
ProtocolField
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ This will take care of basic changes, such as adding new fields and applying def
|
|||
|
||||
.. Note::
|
||||
|
||||
The current version will always be saved as an attirbute on the model xml (e.g. :code:`<Alias version="1.0.0">`)
|
||||
The current version will always be saved as an attribute on the model xml (e.g. :code:`<Alias version="1.0.0">`)
|
||||
|
||||
|
||||
.............................
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@ unparsable data would look like :code:`{"myform": {"myintval": "1x"}}`, in which
|
|||
updateServiceControlUI
|
||||
----------------------------
|
||||
|
||||
The code:`updateServiceControlUI(serviceName)` function hooks the service control on top of the standard template, where you can find
|
||||
The :code:`updateServiceControlUI(serviceName)` function hooks the service control on top of the standard template, where you can find
|
||||
the [re]start, stop and status of the service.
|
||||
|
||||
It assumes the following endpoints exists for the module:
|
||||
|
|
@ -194,7 +194,7 @@ Informational dialog with a single close button, using the following parameters:
|
|||
* message: :code:`string` dialog message
|
||||
* close: :code:`string` close button text
|
||||
* callback: :code:`function()` to be called after close
|
||||
* type: :code:`string` dialog type. one of : danger, default, info, primary, success, warning
|
||||
* type: :code:`string` dialog type. one of: danger, default, info, primary, success, warning
|
||||
* cssClass: :code:`string` css class to use
|
||||
|
||||
|
||||
|
|
@ -208,7 +208,7 @@ Ok/Cancel dialog type using the following parameters:
|
|||
* accept: :code:`string` accept button text
|
||||
* decline: :code:`string` decline button text
|
||||
* callback: :code:`function()` to be called after close
|
||||
* type: :code:`string` dialog type. one of : danger, default, info, primary, success, warning
|
||||
* type: :code:`string` dialog type. one of: danger, default, info, primary, success, warning
|
||||
|
||||
|
||||
|
||||
|
|
@ -226,10 +226,10 @@ will call the selected endpoint and show a progress animation (spinner) to the u
|
|||
|
||||
The following parameters can be supplied as data attributes on the target object:
|
||||
|
||||
* endpoint : endpoint to call (e.g. :code:`/api/my/action`)
|
||||
* label : button label text
|
||||
* service-widget : the service widget to refresh after execution, see :code:`updateServiceControlUI()`
|
||||
* error-title : error dialog title
|
||||
* endpoint: endpoint to call (e.g. :code:`/api/my/action`)
|
||||
* label: button label text
|
||||
* service-widget: the service widget to refresh after execution, see :code:`updateServiceControlUI()`
|
||||
* error-title: error dialog title
|
||||
|
||||
The method itself can be feed with callbacks to call before (:code:`onPreAction()`) and after (:code:`onAction()`) execution.
|
||||
|
||||
|
|
@ -293,10 +293,10 @@ can be used to feed actions, such as **set** (set new values, return validation
|
|||
or **toggle** if the record should be enabled or disabled. :code:`info` endpoints are not used very often (and can safely be omitted), these are mainly intended as simple trigger to display an info dialog.
|
||||
|
||||
|
||||
A full example of a basic grid is available in our :doc:`../examples/using_grids` example
|
||||
A full example of a basic grid is available in our :doc:`../examples/using_grids` example.
|
||||
|
||||
In some cases the developer wants to signal the user about the fact that changes need to be applied in order to be active, for this scenario one can use the :code:`data-editAlert`
|
||||
property of the table, which offers the ability to show an alert after changes. Below example would be shown when the table tag contains :code:`data-editAlert="exampleChangeMessage"`
|
||||
property of the table, which offers the ability to show an alert after changes. Below example would be shown when the table tag contains :code:`data-editAlert="exampleChangeMessage"`:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
|
|
@ -308,7 +308,7 @@ property of the table, which offers the ability to show an alert after changes.
|
|||
.. Tip::
|
||||
|
||||
You can access the general settings of the jquery-bootgrid plugin using the :code:`options` property, which can be convenient when you would like to change
|
||||
requests or responses as being exchanged with the server. The available options are described `here <http://www.jquery-bootgrid.com/Documentation#table>`__
|
||||
requests or responses as being exchanged with the server. The available options are described `here <http://www.jquery-bootgrid.com/Documentation#table>`__.
|
||||
|
||||
|
||||
----------------------------
|
||||
|
|
@ -336,7 +336,7 @@ To define a button sending data to `/api/path/to/import_controller`, the followi
|
|||
|
||||
Initializing this button could be done using:
|
||||
|
||||
.. code-block:: php
|
||||
.. code-block:: html
|
||||
|
||||
$("#upload").SimpleFileUploadDlg();
|
||||
|
||||
|
|
@ -353,7 +353,7 @@ We added a couple of settings to the list, which help to extend our plugin a bit
|
|||
|
||||
* useRequestHandlerOnGet
|
||||
|
||||
* Boolean value which enables the use of the request handler when a :code:`get` request is executed ot fetch data for the dialog. This can be used to add parameters to the request.
|
||||
* Boolean value which enables the use of the request handler when a :code:`get` request is executed to fetch data for the dialog. This can be used to add parameters to the request.
|
||||
|
||||
* onBeforeRenderDialog
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue