This content has been marked as final. Show 8 replies
- (q1) Is it in general a good idea to have such mutual dependent task-flows that call each other? If not, please explain. If it is no problem, please suggest a use-case where it applies.Taskflows should be completely decoupled.
A 'called' TF shouldn't need to know anything about its caller(s).
I would rather have:
TFa calls TFb.
+TFb with a general 'task-flow return' activity to return to whoever the caller is.+
Perhaps the example you linked to is just meant to illustrate a technical concept without promoting any specific design pattern.
Thanks for your reply Jang Vijay Singh.
... promoting any specific design patternmakes me wonder ...
- (q2) Does any documentation on task-flow related design patterns or anti-patterns exist?
(I know there is "An Oracle White Paper - June 2010 - Task Flow Design Fundamentals " ...
... but that is not really about task-flow design patterns or anti-patterns,
e.g. these "mutual dependent task-flows " seem to be a good candidate to be documented as "do" or "don't".)
Looking forward to more feedback on (q1) and (q2).
- (q2) Does any documentation on task-flow related design patterns or anti-patterns exist?I did start on general ADF antipatterns
on the ADF EMG and was going to add to that document 'soon'.
Do add to it as i've seen you post on that group recently.
a good way to look at task flows is as a service with a UI attached to it. The task flow input parameters and output parameters are the contract that is defined between the client (consumer) and the service provider (the task flows). The implementation of the task flow - like in Web Services - is a detail that only the developer of the task flow need to know
Thanks for your reply Jang Vijay.
Thank you for referring to the discussion thread "How about a document on Anti Patterns?"
Thanks for your reply Frank.
I am not sure how to interpret your contract/implementation argument in the context of question (q1). It seems to suggest that "mutual dependent task-flows" should not be a problem in that respect, but it also does not confirm that it is a good idea in general to have such mutual dependent task-flows that call each other.
see also discussion thread "(anti-)patterns [was: How about a document on Anti Patterns?] "