mistercrunch commented on issue #31932:
URL: https://github.com/apache/superset/issues/31932#issuecomment-3194724583
Currently working on two features that may land as Preset-only extensions,
and had a bit of a thought to share about our code structure, wanted to surface
here.
Mostly thinking about the backend currently, but this relates to the
frontend as well. Say if I'm building a "global search" extensions, i'll need a
set of building blocks, like models/views/daos/commands/ ...
Now in our codebase, sometimes things are implemented by type and scattered
through things like:
- superset/models/..
- superset/view/...
- superset/command/...
- superset/daoes/...
Now for my extension, it'd be kind of nice to structure it more like:
- superset/{feature}/models.py
- superset/{feature}/models.py
- superset/{feature}/commands.py
- superset/{feature}/daos.py
Not sure exactly what that means and whether:
- fundamentally the Superset codebase should be more structured in that way
(?) OR
- we need some sort of registry for each object type, and extensions can
inject into them, as in `extension.register_views()`
`extension.register_commands()` `extension.register_blueprints()`
In any case, raises the questions of what I have access to from the
extension SDK, probably access to BaseAPI, BaseCommand, ..., and some ways to
register my stuff somehow ... Not sure if the SIP or related document
formalizes that stuff already or if that's still in up for definition. But
really curious around the mechanics of things. My recent projects are
interesting use cases to figure out:
- what objects I need a handle on for extension (base objects to extend)
- what objects I need to inject (commands, api endpoint/views, models, ...)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
