Osm Admin: Roadmap
1 year ago ∙ 2 minutes read
My current goal is to get some minimum Osm Admin user interface and API working - just for one property, one data type, one UI control type, and then improve.
And there is a lot of space for improvement. The main areas are listed in this document.
I'd really appreciate a helping hand, so if you are into this sort of things, DM me on Twitter.
- Schema Validation
- Altering Existing Tables
- Data Types
- Input Validation
- Property Formulas
- UI Controls
- Filtering, Sorting And Search
- Infinite Scrolling
- Keyboard Navigation
- Documentation And Tests
It should be safe to write anything in a data class definition, and Osm Admin should provide meaningful error messages.
Currently, Osm Admin expects valid attributes and their combinations.
Altering Existing Tables
It should be safe to change anything in a data class definition, and Osm Admin should modify existing table preserving existing data. Renaming a column, or changing a column type should work seamlessly.
Currently, altering existing tables is not supported.
SELECT, INSERT, UPDATE and DELETE should work with all data types, including objects, arrays, and record references.
Currently, only scalar values are supported.
Validation should occur both in frontend, and in backend. In addition to property-level validation, the backend should perform object-level validation. For example, "order must have at least one line", "there can be only one root category".
Currently, there is input validation is not implemented.
You may specify a formula for computing a property value from other properties of the current and related objects. It can be:
#[Computed]- stored in the database
#[Virtual]- computed every time a SELECT query is performed
#[Overridable]- stored in the database, but a user can enter a custom value
Property formulas should run in backend when "source" objects are modified, mostly asynchronously.
Property formulas should also run in the edit form, so if you edit a property, dependent property are recalculated. Form title should also change as you edit the
Currently, property formulas are not implemented.
Scalars can be displayed as
Inner objects can be displayed as
#[Controls] - a block of UI controls, one for each property of the inner object.
Record references can be displayed as
Arrays can be displayed, as
These UI controls should work with all appropriate property types.
After implementing initial prototype, only
#[Input] will be implemented, and only for working with
Filtering, Sorting And Search
Properties may be marked as:
#[Filterable], and appear in a filter block on grid and form pages, and in a grid column context menu, and in a grid context menu.
#[Searchable], and added to an ElasticSearch index. User can full-text search objects of a specific type, or of any type.
#[Sortable], and appear in a grid column context menu, and in a grid context menu.
The grid uses
ui_query() function to orchestrate filtering, sorting and searching. If a search index exists, it should first query the search index, and then the database. If the search index is not available, it should perform filtering and sorting in the database and get the same results.
Currently, filtering, sorting and search are not implemented.
A grid should be able to work with large amounts of data.
It should appear as if it loads all matching objects, but actually, only load visible objects, and load the rest as user scrolls down/up.
After implementing initial prototype, grids will load all objects.
A keyboard-only user should be as comfortable using Osm Admin as mouse/touch user. Navigating the page, invoking context menus, using keyboard shortcuts.
Currently, keyboard navigation is not implemented.
Osm Admin should provide a consistent way of customizing everything:
- custom query actions (in addition to CRUD)
- custom grid views (for the same type of objects)
- custom query logic
- custom controller logic
- custom UI controls
- custom filter types
- custom indexing logic
- custom validation rules
- custom class/property attributes
Currently, you can customize everything using dynamic traits, but for the listed use-cases, a more straightforward approach is needed.
Documentation And Tests
An easy-to-follow documentation should be written, and kept up to date.
Automated tests should have enough coverage to give users confidence to use Osm Admin, and kept up to date.
Currently, the documentation only contains some introduction, installation instruction, and class diagrams, and the test suites are mainly used for TDD.