rahix/openflexure-microscope-server
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Updated to new LabThings structure

Browse source
This commit is contained in:
Joel Collins 2020-09-04 15:48:52 +01:00
parent 304e620143
commit 5139b24ffe
14 changed files with 99 additions and 274 deletions
Download patch file Download diff file Expand all files Collapse all files

8
docs/source/extensions/structure.rst
View file

@ -1,10 +1,10 @@
Basic extension structure
=========================
An extension starts as a simple instance of :py:class:`labthings.server.extensions.BaseExtension`.
An extension starts as a simple instance of :py:class:`labthings.extensions.BaseExtension`.
Each extension is described by a single ``BaseExtension`` instance, containing any number of methods, API views, and additional hardware components.
In order to access the currently running microscope object, use the :py:func:`labthings.server.find.find_component` function, with the argument ``"org.openflexure.microscope"``. Likewise, any new components attached by other extensions can be found using their full name, as above.
In order to access the currently running microscope object, use the :py:func:`labthings.find_component` function, with the argument ``"org.openflexure.microscope"``. Likewise, any new components attached by other extensions can be found using their full name, as above.
A simple extension file, with no API views but application-available methods may look like:
@ -15,7 +15,7 @@ Once this extension is loaded, any other extensions will have access to your met
.. code-block:: python
from labthings.server.find import find_extension
from labthings import find_extension
def test_extension_method():
# Find your extension. Returns None if it hasn't been found.
@ -29,7 +29,7 @@ Once this extension is loaded, any other extensions will have access to your met
Subclassing ``BaseExtension``
-------------------------------
The syntax used above allows novice programmers to easily start building extensions, without having to deal with subclassing. However, for more complex extensions which require persistent state, subclassing :py:class:`labthings.server.extensions.BaseExtension` is recommended.
The syntax used above allows novice programmers to easily start building extensions, without having to deal with subclassing. However, for more complex extensions which require persistent state, subclassing :py:class:`labthings.extensions.BaseExtension` is recommended.
The same simple extension as seen above can be written using subclassing: