neos
TASK: FlowQuery: Add magic methods with params and return types for IDE autocompletion
FlowQuery methods are built on magic methods. That is why there is no autocompletion available in IDEs. Available methods are added as doc header which provide autocompletion.
Checklist
- [x] Code follows the PSR-2 coding style
- [ ] Tests have been created, run and adjusted as needed
- [x] The PR is created against the lowest maintained branch
- [ ] Reviewer - PR Title is brief but complete and starts with
FEATURE|TASK|BUGFIX - [ ] Reviewer - The first section explains the change briefly for change-logs
- [ ] Reviewer - Breaking Changes are marked with
!!!and have upgrade-instructions
Please verify the annotations! The documentation is not very clear about most of the methods.
See https://neos.readthedocs.io/en/stable/References/FlowQueryOperationReference.html
This change introduces a "dependency" (the use and annotation) on the node interface which is not required by Eel normally. We are not sure that ContentRepository methods are available at all time (depends on use case)
At the same time homemade eelhelpers are not registered either in this case?
I see where you want to go, but I see that we are missing the points mentioned above.
Maybe other have some knowledge about how we can solve this - maybe in terms of "phpstorm meta file" configuration
My understanding of the php meta file is that you define property types and return types but you can't define methods, or?
See my comment to get rid of the use statement. For the general case of adding methods, maybe https://www.jetbrains.com/help/phpstorm/ide-advanced-metadata.html#map does indeed work when just defining methods there as if they existed? Or maybe some juggling with the __call method specifically and allowed arguments? Maybe @kdambekalns knows a little bit better
If this whole thing would have been built upon a factory, it would be much easier to resolve.
If this whole thing would have been built upon a factory, it would be much easier to resolve.
Can you explain that? How would a factory help with providing completion for "dynamically registered" operations?
If this whole thing would have been built upon a factory, it would be much easier to resolve.
Can you explain that? How would a factory help with providing completion for "dynamically registered" operations?
Something like FlowQuery::get('filter')->... but of course that would be a totally different syntax.
Something like
FlowQuery::get('filter')->...but of course that would be a totally different syntax.
Ah, yep, got it.
i get the dilemma, but it seems there isnt much we can do (without producing spaghetti code) i like the phpstorm meta syntax idea if it works... or maybe writing a phpstorm plugin could help ...
otherwise we need to wait until we find something better than FlowQuery which is in discussion from time to time ;)
