Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to implement non-node-aware SelectEditor DataSources #893

Open
skurfuerst opened this issue Sep 6, 2017 · 1 comment
Open

Allow to implement non-node-aware SelectEditor DataSources #893

skurfuerst opened this issue Sep 6, 2017 · 1 comment
Labels
Enhancement Extensibility Feature Stale Features to be conceptualized and specified or better to be implemented as a plugin Performance

Comments

@skurfuerst
Copy link
Member

skurfuerst commented Sep 6, 2017

currently, the data sources for the SelectEditor always get the current node passed in as parameter. However, many data sources do not depend on the current node at all. If we had this information in the UI, we could optimize the loading of data sources to cache them more aggressively; leading to a better performance when using many data sources and switching nodes.

Implementation Idea

  • I'd suggest to add an additional interface on the PHP side. This is a little more difficult to implement (as this info is not existing in the UI right from the start), but is a lot cleaner than introducing another data source parameter I think.
  • Using Reflection (and compileStatic), we fetch this information, and send it as part of the config to the UI. Alternatively, we could send it as part of the first response.

Related idea

  • Add DataSources which can do server-side filtering, e.g. sending the search term to the server!

Timeframe

This is all post-1.0-relevant I think. I just wanted to write it down while working on #764

@dimaip
Copy link
Contributor

dimaip commented Sep 9, 2018

@skurfuerst is this something you still want to do/make sense of doing? If not I'd close the issue.

@mhsdesign mhsdesign added the Feature Stale Features to be conceptualized and specified or better to be implemented as a plugin label Oct 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Extensibility Feature Stale Features to be conceptualized and specified or better to be implemented as a plugin Performance
Projects
None yet
Development

No branches or pull requests

4 participants