|
| 1 | +# The `Show` class |
| 2 | + |
| 3 | +!!! warning |
| 4 | + This section is for advanced usage. Please read the [Quick Start](/quickstart/) guides first. |
| 5 | + |
| 6 | +!!! note |
| 7 | + This section asumes a Python-first approach for simplicity. |
| 8 | + You can use all of `auditorium` features in a Markdown-first approach |
| 9 | + with [runnable code blocks](/quickstart/#markdown-first). |
| 10 | + |
| 11 | +The `Show` class is the first class you will need to interact |
| 12 | +with when using `auditorium`. All your slideshows begin with something like: |
| 13 | + |
| 14 | +```python |
| 15 | +from auditorium import Show |
| 16 | + |
| 17 | +show = auditorium.Show("My Show Title") |
| 18 | +``` |
| 19 | + |
| 20 | +## Creating slides |
| 21 | + |
| 22 | +The most important use of your `show` instance is the `@slide` decorator, which |
| 23 | +allows you to create slides. A slide is created by decorating a function (or actually any callable) |
| 24 | +with `@show.slide` like this: |
| 25 | + |
| 26 | +```python |
| 27 | +@show.slide |
| 28 | +def first_slide(ctx): |
| 29 | + # content |
| 30 | +``` |
| 31 | + |
| 32 | +Everything that can be included **inside** a slide is discussed in the [Context](/api/context/) page. |
| 33 | + |
| 34 | +!!! note |
| 35 | + Slides are sorted in the order in which they are declared in your Python script. |
| 36 | + |
| 37 | +### Customizing slides |
| 38 | + |
| 39 | +The `@slide` decorator can receive an optional parameter `id` to configure a specific slide. |
| 40 | + |
| 41 | +```python |
| 42 | +@show.slide(id="the-first-slide") |
| 43 | +def first_slide(ctx): |
| 44 | + # content |
| 45 | +``` |
| 46 | + |
| 47 | +The slide identifier is used in HTML as anchor for that slide. Hence, when running |
| 48 | +the slideshow, the previous slide would be located at `http://localhost:6789/#/the-first-slide`. |
| 49 | +If no `id` is provided the slide identifier is built from the callable `__name__` parameter, |
| 50 | +hence in the previous example it would be located at `http://localhost:6789/#/first_slide` |
| 51 | + |
| 52 | +!!! warning |
| 53 | + Note that when using additional parameters, you have to use the form `@show.slide(...)` |
| 54 | + with parenthesis, but when not using parameters, you can use the decorator directly as |
| 55 | + `@show.slide` without parenthesis. |
| 56 | + |
| 57 | +Default slide ids are OK if you don't care about having those ugly underscores in your slide |
| 58 | +anchors in HTML. In any case, you can always author your slideshow first and then add |
| 59 | +pretty slide identifiers afterwards. |
| 60 | + |
| 61 | +### Vertical slides |
| 62 | + |
| 63 | +Vertical slides are an effective way to add "read-more" like content to a slideshow. |
| 64 | +You can see them in action at <https://auditorium-demo.apiad.net/#/vertical_slides>. |
| 65 | + |
| 66 | +Vertical slides are added *after* a main slide, using a modified form of the `@slide` decorator. |
| 67 | +Instead of using `@show.slide` you use `@main_slide.slide` where `main_slide` is the actual |
| 68 | +function (or any other callable) that corresponds to the main slide. |
| 69 | + |
| 70 | +```python |
| 71 | +@show.slide |
| 72 | +def main_slide(ctx): |
| 73 | + # This will be a regular slide |
| 74 | + |
| 75 | +@main_slide.slide |
| 76 | +def vertical_1(ctx): |
| 77 | + # This one is vertical to `main_slide` |
| 78 | + |
| 79 | +@show.slide |
| 80 | +def other_slide(ctx): |
| 81 | + # This one is another main slide |
| 82 | + |
| 83 | +@other_slide.slide |
| 84 | +def vertical_2(ctx): |
| 85 | + # This one is vertical to `other_slide` |
| 86 | + |
| 87 | +@other_slide.slide |
| 88 | +def vertical_3(ctx): |
| 89 | + # This one is also vertical to `other_slide`, |
| 90 | + # under the previous (`vertical_2`) |
| 91 | +``` |
| 92 | + |
| 93 | +!!! note |
| 94 | + Vertical slides can be declared at any moment *after* but not necesarily *under* the main slide. |
| 95 | + This allows you to organize all your main slides at the top of a script and then add vertical slides when |
| 96 | + you think is convenient. |
| 97 | + |
| 98 | +## Running the show |
| 99 | + |
| 100 | +Once all slides are in, you can run a show by calling directly the `show.run` method: |
| 101 | + |
| 102 | +```python |
| 103 | +show.run('localhost', 6789) |
| 104 | +``` |
| 105 | + |
| 106 | +However, this method is actually **not recommended**. Instead it is *preferred* to use: |
| 107 | + |
| 108 | +```bash |
| 109 | +auditorium run /path/to/myshow.py [--host HOST] [--port PORT] |
| 110 | +``` |
| 111 | + |
| 112 | +The second method is preferred because it is more aligned with other usages such as `auditorium publish` |
| 113 | +and, in the future, we will add a `--reload` option to allow hot-reload when you save your slideshow. |
| 114 | + |
| 115 | +!!! error |
| 116 | + When calling `run` you can get an error like: |
| 117 | + |
| 118 | + :::bash |
| 119 | + (!) You need `uvicorn` installed in order to call `run`. |
| 120 | + |
| 121 | + This means you didn't installed `uvicorn` when installing `auditorium`, which is necessary |
| 122 | + for actually serving the HTML. You can fix it by installing like this: |
| 123 | + |
| 124 | + pip install auditorium[server] |
| 125 | + |
| 126 | + Serverless installations are smaller and useful if you only want to use `render` or `publish`, |
| 127 | + or [deploy to a serverless cloud provider](/hosting/#hosting-as-serverless-functions-at-nowsh). |
| 128 | + |
| 129 | +## Rendering the show |
| 130 | + |
| 131 | +You can obtain a static HTML with embedded resources ready to be served with: |
| 132 | + |
| 133 | +```python |
| 134 | +static_html = show.render(theme="white") |
| 135 | + |
| 136 | +with open("/path/to/myshow.html", "w") as fp: |
| 137 | + fp.write(static_html) |
| 138 | +``` |
| 139 | + |
| 140 | +The reason why `render` returns a `string` rather than saving to a file is because you could |
| 141 | +use this functionality in a serverless cloud provider or any other context where you cannot |
| 142 | +interact directly with path-based files. It's up to you how to make use of the rendered HTML. |
| 143 | + |
| 144 | +That said, if you use the [CLI command](/api/cli) `render` you can achieve this more easily with: |
| 145 | + |
| 146 | +```python |
| 147 | +auditorium render /path/to/myshow.py > /path/to/myshow.html |
| 148 | +``` |
| 149 | + |
| 150 | +## Loading a show |
| 151 | + |
| 152 | +The static method `Show.load` takes in a path and loads the corresponding show instance. |
| 153 | + |
| 154 | +```python |
| 155 | +show = Show.load("/path/to/show.py") |
| 156 | +``` |
| 157 | + |
| 158 | +It works with both Python (`myshow.py`) and Markdown (`myshow.md`) file extensions. |
| 159 | +It is useful in contexts where you can serve multiple slideshows, for example, |
| 160 | +in a server context where you want to map URL paths to specific shows. |
| 161 | + |
| 162 | +After calling `load` you receive a `Show` instance with all it can do. |
| 163 | + |
| 164 | +## Appending multiple shows |
| 165 | + |
| 166 | +You can build a slideshow in parts, some in Python, some in Markdown, and then |
| 167 | +use `show.append` to connect them. It works with `Show` instances and path names as well. |
| 168 | + |
| 169 | +```python |
| 170 | +show = Show("Main Show") |
| 171 | +# ... build show |
| 172 | + |
| 173 | +# append another instance |
| 174 | +other_show = Show("Other show") |
| 175 | +# ... build other_show |
| 176 | +show.append(other_show) |
| 177 | + |
| 178 | +# append by path |
| 179 | +show.append("/path/to/anothershow.py") # Python |
| 180 | +show.append("/path/to/anothershow.md") # Markdown |
| 181 | +``` |
| 182 | + |
| 183 | +This allows you to build a slideshow in parts. Maybe some slides are more |
| 184 | +convenient in Markdown-first mode because they are mostly static content, |
| 185 | +while a few specific slides are very tricky and it's better to code them in Python. |
| 186 | + |
| 187 | +!!! warning |
| 188 | + This section is under construction. More content will be added shortly. |
0 commit comments