-
Notifications
You must be signed in to change notification settings - Fork 0
Examples and tests
Examples of all the types of routes explained in the adding routes section can be found in the tests folder in the github repository. The main test file is autotest.py. Most of the functions it imports and tests can be found in simple_functions.py. You can donwload this folder and execute the tests yourself to get a better understanding of how autofront works. It's also included in the distribution if you know where to find it on your system (typically in your virtual environment in lib/pythonx.x/site-packages/autofront/tests).
While autofront attempts to accomodate a wide range of needs, a typical user wanting to use it as a remote control and display for a project might only ever need the simplest route:
autofront.add(my_function)
There are five differents test scripts used for autofront.
- Test suite
- Custom static folder
- Custom templates folder
- Default inititalization
- Detect functionality
Running the test suite can be a great introduction to autofront's possibilities. It also lets you know if autofront is working properly on your system. Since it's still in early alpha, this is not guaranteed. You can also have a look at the custom static and template tests to discover the syntax. The other two scripts are mostly used for code-testing during development. Anyone wanting to contribute to autofront's development should run all five test scripts to ensure their proposed changes don't break anything.
autotest.py is the main test suite for autofront. It's also a good reference for the syntax used in different routes. If you're having trouble adding a route, the first step should probably be to find a similar route in autotest and make sure it works on your system. If it does, check to make sure you've followed the same syntax when adding your route.
If you're having problems running routes in general, the first step should be to make sure autotest.py runs correctly on your system. Here is the code, required input (if any) and the expected output for each route in the test suite.
NOTE: Most routes specify join=True for faster execution. This is only possible for routes that do not use input calls, as explained here. This is optional and beginners can simply ignore the join keyword argument.
autofront.add(foo, join=True)
bar
This is the basic syntax used to execute a function that requires no arguments at all. It uses a print call and returns nothing.
autofront.add(foo_args, 'arg1', 'arg2', kwarg1='Surprise!', kwarg2='Aha!', join=True)
arg1 arg2 Surprise! Aha!
Use this syntax to run a function using the same arguments each time. Start with the function itself, then the positional arguments in order, then the keyword arguments in any order.
autofront.add(return_value, join=True)
Return value: foo
This also follows the basic syntax, but the output comes from the return value instead of a print call.
autofront.add('simple_script.py', join=True)
__main__
[local script filepath]
It works!
This is the basic syntax used to run a script with no command line arguments. It should output its __name__ attribute (which should be __main__), its __file__ attribute (which should point to the autofront local directory), and finally a success message ('It works!').
autofront.add('simple_script_args.py', 'foo', 'bar', 'foobar', join=True)
It works!
Here are your args:
'foo'
'bar'
'foobar'
Use this syntax to run a script with the same fixed command-line arguments every time. Start with the script path, then the command-line arguments in order. If your script is not in the same directory, you'll need to specify the full absolute or relative path.
autofront.add('simple_script_args.py', link='forgotargs', join=True,
title='simple_script_args.py without args')
It works!
But you forgot the args
This points to the same script as the previous route. Routes pointing to the same script or function must be differentiated using the 'title' keyword argument. This will be the text used to identify the function in the browser. The 'link' keyword argument is optional and lets you specify a specific url to point to. By default, this is identical to 'title' and there is typically no reason to change it.
autofront.add('import_script.py', join=True)
[System path]
[Current working directory]
[__file__]
The system path should start with the autotest.py directory, followed by the directory where autofront is installed. The current working directory should be where autotest.py is located. __file__ should be a script located in autofront/local in your autofront installation.
autofront.add('input_script.py')
Script should ask you twice to input something in the browser. Choose what you want.
first input: [your first input]
second input: [your second input]
This tests that script input calls function properly. Clicking on this route should open a browser page asking for input two times and print the result in the browser. There is no need to change the route syntax unless input detection fails. If this happens, you can add the keyword argument 'input_call=True' to force autofront to expect a possible input call.
autofront.add('conditional_input_script.py', live=True)
If you enter a single argument in the live argument box on the main page, the script will ask you to play a simple matching game by entering it a second time on the input page.
If you enter more than one argument on the main page, it won't ask for input.
If you entered an argument in the live argument box and the same one on the input page:
You won!
If you entered an argument in the live argument box and a different one on the input page:
You lost!
If you entered more than one argument in the live args:
Can't play match the args with so many args!
autofront.add('test_joelle.py')
This is a simple cat game with a hidden ending, written by my niece. I keep it in the test suite out of nostalgia, as it is conceptually similar to the regular input script test. It did catch one bug that had slipped through! Feel free to play it or not as you wish.
autofront.add(input_function)
Enter any two values in the input prompts.
Return value: They said [input1] and [input2]
This test checks if input functions work properly. It's basically identical to the input script test, except that it's a function.
autofront.add('background_script.py', join=False)
The join=False keyword argument tells autofront not to wait for the script to finish execution before returning to the main page. The same syntax works for functions.
Before running this test, make sure to delete logger.txt in the tests folder.
After 3 seconds, the script should write Time elapsed to a file called logger.txt in the tests folder.
autofront.add('background_script.py', join=True, title='timeout test', timeout=2)
background_script.py timed out before completion.
You can change the timeout value with a kwarg:
autofront.add(my_function, timeout=value_in_seconds)
This uses the same script, but uses a timeout value lower than the script takes to complete (timeout=2) and waits for it to complete (join=True). It would still wait for completion without the join kwarg, as long as it's not set to False.
autofront.add(positional, live=True, join=True)
Type the following in the input box: foo, bar
Positional bar foo
Tests live positional arguments. All arguments are interpreted as strings unless the typed=True keyword argument is used.
autofront.add(keywords, live=True, join=True)
kwarg1=foo, kwarg2=bar
Keywords: bar foo
Tests live keyword arguments. Ignores spaces around the equal sign if any.
autofront.add(combined, live=True, join=True)
foo, bar, kwarg1=foobar, kwarg2=barfoo
Combined: barfoo foobar bar foo
autofront.add(mixed_args, 'fixed1', 'fixed2', live=True, join=True)
foo, bar, kwarg1=foobar, kwarg2=barfoo
Builtin: foobar barfoo bar foo fixed2 fixed1
This syntax is for functions that combine built-in positional arguments with live arguments.
autofront.add(return_value_args, live=True, join=True)
foo, bar, kwarg1=foobar, kwarg2=barfoo
Return value: ['foo', ' bar', 'foobar', 'barfoo']
autofront.add('simple_script_live.py', live=True, join=True)
Any number of words separated by spaces. Ex: arg1 arg2
Runtime arguments: [local script filepath, 'arg1', ' arg2']
Note that the syntax for scripts uses the standard command-line syntax with arguments separated by spaces instead of commas. To keep things simple for the user, separating arguments with commas will also work.
autofront.add(types, live=True, typed=True, join=True)
bool:True, list:[int:3, str:4], dict:{str:foo : tuple:(float:3.4, int:4)}
Here are your args and their type:
True <class 'bool'>
[3, '4'] <class 'list'>
{'foo': (3.4, 4)} <class 'dict'>
Go here to read more about the type indication syntax.
autofront.add(types_kwarg, live=True, typed=True, join=True)
str:foo, int:4, str:bool1=bool:True, str:bool2=bool:False
Here are your args and their type:
foo <class 'str'>
4 <class 'int'>
Here are your kwargs and their type:
Key: bool1 <class 'str'>
Value: True <class 'bool'>
Key: bool2 <class 'str'>
Value: False <class 'bool'>
autofront.add(return_value_types_args, live=True, typed=True, join=True)
int:3, str:a, str:kwarg1=int:4
Return value: [(3, 'a'), {'kwarg1': 4}]
autofront.add(bugged_function)
IndexError
list index out of range
By default, autofront displays exceptions encoutered by your functions and scripts in the browser. This behavior can be changed to print them in the console when initializing autofront:
autofront.initialize(print_exceptions=False)
Note that exceptions raised by autofront itself will be raised as normal and the error message will print to the console, not the browser. It's also possible that some exceptions in your functions and scripts will fail to print to the browser. When an exception can't be handled by autofront, an error page will be displayed and you can find the debugging information in the console.
autofront.add('bugged_script.py')
Traceback (most recent call last):
File "/Users/jimmy/Programming/Python/autofront/autofront/local/bugged_script.py", line 9, in <module>
divsion_by_zero = 1/0
ZeroDivisionError: division by zero
Script execution exceptions should also be displayed in the browser.
statictest.py is used to make sure custom static folders are loaded properly.
This should simply load the standard test suite. Text should be in red.
NOTE: Because browsers cache CSS files, the text might appear not to have changed. Either clear the cache or use a different browser for this test.
templatetest.py is used to make sure custom template files are loaded properly.
This should simply add Template Test at the top of the page, before the standard test suite. Output should print at the bottom of the page.
detect_test.py tests two routes to ensure functions and scripts are detected properly.
autofront.add(detect_function)
This is a function
autofront.add('detect_script.py')
This is a script