MrDraw/docs/jsclientlib/control.rst

58 lines
2.5 KiB
ReStructuredText
Raw Permalink Normal View History

Allow multiple instances of the JS client We now have a global OctoPrintClient, which is the class from which all clients are derived, and a global OctoPrint, which is a single instance already setup and ready to use in case we only need one. It would be cleaner to have clients create that singular instance themselves, but we need to maintain backward compatibility for now with how we established the client to work with the 1.3.0 release. New clients can be create with client = new OctoPrintClient({ /* options */ }); Alternatively the options can be left out and set at a later point: client = new OctoPrintClient(); /* ... */ client.options = { /* options */ }; Individual client components register themselves with OctoPrintClient via OctoPrintClient.registerComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.<name>", e.g. "OctoPrint.files". Plugin components register themselves with OctoPrintClient via OctoPrintClient.registerPluginComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.plugins .<name>", e.g. "OctoPrint.plugins.softwareupdate". This should make it possible to create dashboard pages utilizing the JS client that monitor the status of multiple OctoPrint instances, without workarounds such as having to swap out the options globally before each request. See #1681 for the corresponding discussion.
2017-01-20 10:34:19 +00:00
.. _sec-jsclientlib-control:
2016-06-15 07:47:32 +00:00
Allow multiple instances of the JS client We now have a global OctoPrintClient, which is the class from which all clients are derived, and a global OctoPrint, which is a single instance already setup and ready to use in case we only need one. It would be cleaner to have clients create that singular instance themselves, but we need to maintain backward compatibility for now with how we established the client to work with the 1.3.0 release. New clients can be create with client = new OctoPrintClient({ /* options */ }); Alternatively the options can be left out and set at a later point: client = new OctoPrintClient(); /* ... */ client.options = { /* options */ }; Individual client components register themselves with OctoPrintClient via OctoPrintClient.registerComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.<name>", e.g. "OctoPrint.files". Plugin components register themselves with OctoPrintClient via OctoPrintClient.registerPluginComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.plugins .<name>", e.g. "OctoPrint.plugins.softwareupdate". This should make it possible to create dashboard pages utilizing the JS client that monitor the status of multiple OctoPrint instances, without workarounds such as having to swap out the options globally before each request. See #1681 for the corresponding discussion.
2017-01-20 10:34:19 +00:00
:mod:`OctoPrintClient.control`
------------------------------
2016-06-15 07:47:32 +00:00
Allow multiple instances of the JS client We now have a global OctoPrintClient, which is the class from which all clients are derived, and a global OctoPrint, which is a single instance already setup and ready to use in case we only need one. It would be cleaner to have clients create that singular instance themselves, but we need to maintain backward compatibility for now with how we established the client to work with the 1.3.0 release. New clients can be create with client = new OctoPrintClient({ /* options */ }); Alternatively the options can be left out and set at a later point: client = new OctoPrintClient(); /* ... */ client.options = { /* options */ }; Individual client components register themselves with OctoPrintClient via OctoPrintClient.registerComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.<name>", e.g. "OctoPrint.files". Plugin components register themselves with OctoPrintClient via OctoPrintClient.registerPluginComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.plugins .<name>", e.g. "OctoPrint.plugins.softwareupdate". This should make it possible to create dashboard pages utilizing the JS client that monitor the status of multiple OctoPrint instances, without workarounds such as having to swap out the options globally before each request. See #1681 for the corresponding discussion.
2017-01-20 10:34:19 +00:00
.. js:function:: OctoPrintClient.control.getCustomControls(opts)
2016-06-15 07:47:32 +00:00
Retrieves the defined custom controls from the server.
:param object opts: Additional options for the request
:returns Promise: A `jQuery Promise <http://api.jquery.com/Types/#Promise>`_ for the request's response
Allow multiple instances of the JS client We now have a global OctoPrintClient, which is the class from which all clients are derived, and a global OctoPrint, which is a single instance already setup and ready to use in case we only need one. It would be cleaner to have clients create that singular instance themselves, but we need to maintain backward compatibility for now with how we established the client to work with the 1.3.0 release. New clients can be create with client = new OctoPrintClient({ /* options */ }); Alternatively the options can be left out and set at a later point: client = new OctoPrintClient(); /* ... */ client.options = { /* options */ }; Individual client components register themselves with OctoPrintClient via OctoPrintClient.registerComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.<name>", e.g. "OctoPrint.files". Plugin components register themselves with OctoPrintClient via OctoPrintClient.registerPluginComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.plugins .<name>", e.g. "OctoPrint.plugins.softwareupdate". This should make it possible to create dashboard pages utilizing the JS client that monitor the status of multiple OctoPrint instances, without workarounds such as having to swap out the options globally before each request. See #1681 for the corresponding discussion.
2017-01-20 10:34:19 +00:00
.. js:function:: OctoPrintClient.control.sendGcode(commands, opts)
2016-06-15 07:47:32 +00:00
Sends the provided ``commands`` to the printer.
Corresponds to the :ref:`Send an arbitrary command to the printer <sec-api-printer-arbcommand>` API,
see there for details.
:param list or string commands: One or more commands to send to the printer.
:param object opts: Additional options for the request
:returns Promise: A `jQuery Promise <http://api.jquery.com/Types/#Promise>`_ for the request's response
Allow multiple instances of the JS client We now have a global OctoPrintClient, which is the class from which all clients are derived, and a global OctoPrint, which is a single instance already setup and ready to use in case we only need one. It would be cleaner to have clients create that singular instance themselves, but we need to maintain backward compatibility for now with how we established the client to work with the 1.3.0 release. New clients can be create with client = new OctoPrintClient({ /* options */ }); Alternatively the options can be left out and set at a later point: client = new OctoPrintClient(); /* ... */ client.options = { /* options */ }; Individual client components register themselves with OctoPrintClient via OctoPrintClient.registerComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.<name>", e.g. "OctoPrint.files". Plugin components register themselves with OctoPrintClient via OctoPrintClient.registerPluginComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.plugins .<name>", e.g. "OctoPrint.plugins.softwareupdate". This should make it possible to create dashboard pages utilizing the JS client that monitor the status of multiple OctoPrint instances, without workarounds such as having to swap out the options globally before each request. See #1681 for the corresponding discussion.
2017-01-20 10:34:19 +00:00
.. js:function:: OctoPrintClient.control.sendGcodeWithParameters(commands, parameters, opts)
2016-06-15 07:47:32 +00:00
Sends the provided ``commands`` to the printer, replacing contained placeholders with
the provided ``parameters`` first.
Corresponds to the :ref:`Send an arbitrary command to the printer <sec-api-printer-arbcommand>` API,
see there for details.
:param list or string commands: One or more commands to send to the printer
:param object parameters: Parameters (key-value-pairs) to replace placeholders in ``commands`` with
:param object opts: Additional options for the request
:returns Promise: A `jQuery Promise <http://api.jquery.com/Types/#Promise>`_ for the request's response
Allow multiple instances of the JS client We now have a global OctoPrintClient, which is the class from which all clients are derived, and a global OctoPrint, which is a single instance already setup and ready to use in case we only need one. It would be cleaner to have clients create that singular instance themselves, but we need to maintain backward compatibility for now with how we established the client to work with the 1.3.0 release. New clients can be create with client = new OctoPrintClient({ /* options */ }); Alternatively the options can be left out and set at a later point: client = new OctoPrintClient(); /* ... */ client.options = { /* options */ }; Individual client components register themselves with OctoPrintClient via OctoPrintClient.registerComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.<name>", e.g. "OctoPrint.files". Plugin components register themselves with OctoPrintClient via OctoPrintClient.registerPluginComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.plugins .<name>", e.g. "OctoPrint.plugins.softwareupdate". This should make it possible to create dashboard pages utilizing the JS client that monitor the status of multiple OctoPrint instances, without workarounds such as having to swap out the options globally before each request. See #1681 for the corresponding discussion.
2017-01-20 10:34:19 +00:00
.. js:function:: OctoPrintClient.control.sendGcodeScript(script, context, opts)
2016-06-15 07:47:32 +00:00
Sends the provided ``script`` to the printer, enhancing the template with the
specified ``context``.
:param string script: Name of the script to send to the printer
:param object context: Template context
:param object opts: Additional options for the request
:returns Promise: A `jQuery Promise <http://api.jquery.com/Types/#Promise>`_ for the request's response
Allow multiple instances of the JS client We now have a global OctoPrintClient, which is the class from which all clients are derived, and a global OctoPrint, which is a single instance already setup and ready to use in case we only need one. It would be cleaner to have clients create that singular instance themselves, but we need to maintain backward compatibility for now with how we established the client to work with the 1.3.0 release. New clients can be create with client = new OctoPrintClient({ /* options */ }); Alternatively the options can be left out and set at a later point: client = new OctoPrintClient(); /* ... */ client.options = { /* options */ }; Individual client components register themselves with OctoPrintClient via OctoPrintClient.registerComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.<name>", e.g. "OctoPrint.files". Plugin components register themselves with OctoPrintClient via OctoPrintClient.registerPluginComponent(name, component) from the component JS files. Just like before their instances are then available in the individual client instances under "<client>.plugins .<name>", e.g. "OctoPrint.plugins.softwareupdate". This should make it possible to create dashboard pages utilizing the JS client that monitor the status of multiple OctoPrint instances, without workarounds such as having to swap out the options globally before each request. See #1681 for the corresponding discussion.
2017-01-20 10:34:19 +00:00
.. js:function:: OctoPrintClient.control.sendGcodeScriptWithParameters(script, context, parameters, opts)
2016-06-15 07:47:32 +00:00
Sends the provided ``script`` to the printer, enhancing the template with the
specified ``context`` and ``parameters``.
:param string script: Name of the script to send to the printer
:param object context: Template context
:param object parameters: Template parameters
:param object opts: Additional options for the request
:returns Promise: A `jQuery Promise <http://api.jquery.com/Types/#Promise>`_ for the request's response