-
Notifications
You must be signed in to change notification settings - Fork 1
Roadmap
List of features and priorities internal use only.
- Read and write to idb instead of remote APIs. This is nearly complete. Need to implement query for keyval crud adaptor. Once that is done register data service for panelpagelist using crud data service with idb so panel page discovery queries read from idb instead of remote elastic API abstracted by verti-go.
- Implement caching and multi-request blocking for data service queries so that panel pages render with content properly when using ssr.
- Dynamic entity metadata configurations. This could be done in the short term using factories for things that require persistence. Inside the environment config there could be a property to use a specific data service. Could also add conditions/rules to crud adaptors. I kind of like that. Adding rules to crud adaptor configurations sounds fun. A json engine rule could be optionally included as part of an adaptor metadat configuration to determine whether the adaptor is applied or not. That would open the door to other possibilities as well.
Instead of using rules for crud plugins offline boolean will be added to environment config. The offline flag will determine whether entities in the platform use idb for storage. This will be achieved by simply changing the metadata configuration based on whether offline mode is enabled.
The few last critical pieces to add is operation filters on crud adaptors meta data. This will make it possible to use one adaptor and another for persistence without needing to create a custom data service. Also need to allow content merges. It would be nice to query data from multiple stores like s3 and idb but have entities in idb override those from s3. I don't think that will be difficult to achieve.
Nest steps for crud and entity after this are hooking them up with data sources.
- Charts – Easily add all kinds of charts to pages using datasources. Probably Ngx Charts
- carousel – probably going to use owl carousel unless more appropriate options comes around or is discovered.
- formly repeating sections - nesting entities can currently be achieved using data sources but it is a little slow and convoluted. Also requires custom JS to handle some of the behavior for managing the nested collection. Example being developed and pending for publish.
- ngx data grid - tables can be created using multiple approaches but they all require a bit of custom code like css to achieve. Also they can become slow also limited in features. Makes sense to provide actual data grid option. This is not a high priority though at the moment.
- !Kendo Grid and/or components integration - This is only an idea. Not planned.
- !AgGrid – This is only an idea. Not planned.
- Material Pagination integration into existing table solution using multiple content bindings approach. This is somewhat needed to allow data tables to be created that can be navigated using pagination without someone building their own pagination using links and a snippet.
- Factor snippet out of pages. It is currently its own module but needs to be completely decoupled from pages module.
- Remove slice content plugin from pages module. The slice content plugin is no longer necessary. The data source content plugin provides the same feature set as slice and much more.
- Factor panels content plugin out of pages. The plugin and handler lives in panels module. So I think the code in pages isn't even used but need to verify.
- Remove rest from pages module. Several demo pages rely on rest. Need to determine migration strategy It might just be recreating those pages using data sources and calling it the day. So the demo pages that need to be recreated using rest need to be identified and rebuilt. Once that is done probably can just remove rest since rest is part of data source now.
- AWS InMemory crud adaptor - persistence to managed redis.
- AWS Open Search crud adaptor - persistence to managed open search
- Integrate AWS location into platform. Probably using a style plugin.
This can change but these are some of the ones that have been planned. There can also be recipes that go over building reusable lower level features like forms, data tables, and achieving specific goals with certain features like states.
- Marvel Character Browser
- Tour of Heros
- Product Page
- Data Table
I think I want three primary examples on the root readme.
- Marvel character browser
- Form building - formly kithen sink
- Tour of Heros
These three demos are more than enough to demonstrate the platforms current capabilities.
Changes to CSS using browser dev tools automatically save to page css. So instead of needing to create custom stylesheets an upload them to s3 or whatever. Instead css that is added in edit mode could just be automatically published somehow. This would be a really neat and time saving feature for customizing design of pages. It would also nicely separate responsibilities/role of content editors/page builders and designers.
Implicit solutions for logging, monitoring, and reporting metrics for editor and pages.
Panel page variants - extend panel pages inheriting existing content of parent page. Allow parent page to lock content or place restrictions on content that can be edited on page or child pages. This could be based on contexts like user info perhaps.
Create export of panel pages that can be ingested into test environment and ran through cyprus to validate functionality. Low level features will be represented as panel pages, exported and go through cyprus to test for regressions to intended functionality including visual presentation.
Automate unit tests for models using mocking library probably.
Establish pattern to test plugins.