-
Notifications
You must be signed in to change notification settings - Fork 317
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
Improvement/flexible task iteration #352
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The introduction of get_next_task is very helpful.
TaskFilter is a little more verbose, but also a clean and consistent replacement for many alternate ways to get at things - so it definitely reduces cognitive load.
Things like "_is_decendant_of" are much better as public methods.
I really wish that both get_task and get_task_iterator did not both exist. This creates
new cognitive load.
@@ -216,7 +246,7 @@ def do_engine_steps(self, will_complete_task=None, did_complete_task=None): | |||
def update_workflow(wf): | |||
count = 0 | |||
# Wanted to use the iterator method here, but at least this is a shorter list | |||
for task in wf.get_tasks(TaskState.READY): | |||
for task in wf.get_tasks(state=TaskState.READY): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want get_tasks to remain available, or are we using get_tasks_iterator everywhere now? It seems to jump back and forth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are one or two places where it doesn't work. I am hoping as some of the core library task state change methods are cleaned up more, it will be possible to use the iterator exclusively.
@@ -77,8 +77,8 @@ def create_workflow(self, my_task): | |||
def start_workflow(self, my_task): | |||
subworkflow = my_task.workflow.top_workflow.get_subprocess(my_task) | |||
self.copy_data(my_task, subworkflow) | |||
for child in subworkflow.task_tree.children: | |||
child.task_spec._update(child) | |||
start = subworkflow.get_next_task(spec_name='Start') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so so so much cleaner. What an improvement!
Also, both methods ( The advantage of task filter is that you can extend it if you have custom properties and use your own instead (so for example, you could write a filter in arena's backend that includes spiff properties and pass that in). I added this because there have been many times when I've been hampered by the builtin iterator's capabilities. |
This PR includes
Task
class and better filtering capabilities were addedWorkflow.get_tasks
now takes other keyword arguments besides the state and filters them all at once, in one pass through the treeTaskState
class, which was moved into theSpiffWorkflow.utils.task
module.Task
andWorkflow