You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now our ADO breadcrumbs are very flexible but sometimes when you have multiple levels of relationship between children and parent you might want to be able to choose to e.g exclude from breadcrumb a few predicates or the opposite, force breadcrumb to only work on a few.
Because breadcrumbs use one of our computed field here
that fetches any ADO to ADO relationship, one option would be to allow computed level sub properties
So a getValue() directly on the field will get me all, but another accessor with arguments would allow me to filter out
Another option is to have a second computed one. We could of course simply use this via normal field/data logic (kinda bring out of the class the code and query the JSON directly) but i like computed fields because they abstract and hide complexities and allow us in the future to improve the logic without changing the calling code.
Anyway. This is needed for 1.4.0 before the release
The text was updated successfully, but these errors were encountered:
What?
Right now our ADO breadcrumbs are very flexible but sometimes when you have multiple levels of relationship between children and parent you might want to be able to choose to e.g exclude from breadcrumb a few predicates or the opposite, force breadcrumb to only work on a few.
Because breadcrumbs use one of our computed field here
strawberryfield/strawberryfield.module
Lines 216 to 229 in 5319d10
that fetches any ADO to ADO relationship, one option would be to allow computed level sub properties
So a getValue() directly on the field will get me all, but another accessor with arguments would allow me to filter out
Another option is to have a second computed one. We could of course simply use this via normal field/data logic (kinda bring out of the class the code and query the JSON directly) but i like computed fields because they abstract and hide complexities and allow us in the future to improve the logic without changing the calling code.
Anyway. This is needed for 1.4.0 before the release
The text was updated successfully, but these errors were encountered: