A Conversation around Extensions Design #49
kjaymiller
started this conversation in
Extensions
Replies: 1 comment
-
Check out pluggy when you are ready to add Extensions. It can save you some time and give you some low-effort Also, check out Datasett's hooks for some prior art. https://github.com/simonw/datasette/blob/main/datasette/hookspecs.py |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Site Level Extension Support Proposal
This is a conceptual document and meant to start a conversation on how to implement this feature. No code has been written. This is a proposal for a standard methodology for extension support in Render Engine.
Proposed Extension Render Flow
1.1 Site Render Flow
1.2 Page Render Flow
1.3 Render Collection Flow
Extensions ≠ Custom Objects
The biggest understanding with this is that Extensions are not Custom Objects. That said certain extensions can require a custom endpoints to properly function. You can create Custom Objects to ensure those endpoints are accounted for.
The biggest reason for this distinction is to encourage custom objects to be created liberally in Render Engine.
This allows for maximum flexibility in combining extensions.
Extension Types
Each of the main objects (
Site
,Collection
,Page
) should have a set of extension entry points. These extension points are where extensions can be loaded and executed.Extensions should be called at in the Site().render_<page|collection> or in newly designed
Site().pre_render()
andSite().post_render()
methods.Page Extensions
Page Extensions should only modify the page that
Site().render_page()
is being called on. This could be like adding support for custom parsers/renderers or pre_loading data from another source.Page Extensions are called in the
Site().render_page()
method in the extensions attribute.Collection Extensions
Collection Extensions should modify the collection that
Site().render_collection()
is being called on or the pages in that collection. Like Page_Extensions, this could be like adding support for custom parsers/renderers and for pre_loading data from another source. Collection extensions can also be used to filter pages in the collection to be rendered.Collections also have a
setup
andteardown
entrypoint that can be used to modify the collection input/output before and after it's rendered.Collection Extensions also have a selective filter that can be used to filter pages in the collection to be modified. (Implementation TBD)
Lastly Collection Extension have a
fail_if
attribute that can be used to determine if the collection AS A WHOLE should be rendered or not. (Implementation TBD)Site Extensions
Site Extensions are by design the most diverse types of extensions. They can modify the existing
Site
object. They can also be used to apply a global modifier to ALL pages and collections. There can also be a selective application of extension to only site objects or page objects. This would be similar to the selective filter in Collection Extensions.Site extensions also have similar
setup
andteardown
andfail_if
entrypoints that can be used to create setup/teardown tasks for the entire site. Iffail_if
is triggered the entire site will not be rendered.Extension Packages
Extensions exist as separate python packages. This means that any one extension can be developed to interact in any or all of the entry points. This also means that version dependency will be required to ensure that the extension is compatible with the version of Render Engine in use.
Bundling Extensions and Dependencies
Extensions can be bundled together to create a more cohesive experience. This is done by creating a to be loaded.
Extensions can also be dependent on other extensions. This will create a more programatic way to develop extensions. This will alsl ensure that users can easily install everything needed.
Beta Was this translation helpful? Give feedback.
All reactions