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
When editing a specific task's DashboardListItem I'm going through the items returned by this.TaskManager.GetDashboardContent(this.TaskQueueResolver) and then matching by Title. This adds some unnecessary boilerplate as now I also put the Title inside a const string.
Could we perhaps assign the TaskType string to DashboardListItem.ID?
This string is already used to "look up" the TaskProcessor so this seems like a more natural way to match the DashboardListItem.
The text was updated successfully, but these errors were encountered:
That sounds potentially reasonable. Can you give me some more information on why exactly you're trying to find these list items, though? I'm interested to see whether we should architect access/generation differently to make it more accessible in the first place (rather than having to post-process).
Sometimes I like to add additional commands to the task on the dashboard. For example: we have a service tool that does some mass manipulation of properties based on a configured filter and such. I've also added a "Count" command so that we can check that the amount of objects found matches expectations.
The approach that the current code takes (by using extension methods to generate everything) was quick to implement, but isn't very flexible or extensible, and I don't like the idea of people having to post-process items.
What if we looked to migrate some of this into "Generator" classes/interfaces (IDashboardTaskProcessorGenerator / IDashboardTaskGenerator)? You could then easily extend these classes and add whatever functionality you need, or even create your own implementations if you wanted..
When editing a specific task's DashboardListItem I'm going through the items returned by this.TaskManager.GetDashboardContent(this.TaskQueueResolver) and then matching by Title. This adds some unnecessary boilerplate as now I also put the Title inside a const string.
Could we perhaps assign the TaskType string to DashboardListItem.ID?
This string is already used to "look up" the TaskProcessor so this seems like a more natural way to match the DashboardListItem.
The text was updated successfully, but these errors were encountered: