This commit is contained in:
Joel Collins 2020-09-07 16:33:01 +01:00
commit 2ce58f2aee
10 changed files with 24 additions and 232 deletions

View file

@ -37,8 +37,8 @@ For example, if you are creating an API route, in which you expect parameters ``
.. code-block:: python
from labthings.server.schema import Schema
from labthings.server import fields
from labthings.schema import Schema
from labthings import fields
class UserSchema(Schema):
name = fields.String(required=True)

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:

View file

@ -32,7 +32,7 @@ An example of a long running task may look like:
.. code-block:: python
...
from labthings.server.view import ActionView
from labthings import ActionView
class SlowAPI(ActionView):
def post(self):