Hi All,

I want to invite comments on the best practice to approach a scenario
involving communications from taskflow consumed as region to parent
taskflow in absence of standard action that could raise the contextual
event.

When taking about the Taskflow communications few standard pattern comes to
mind and most of them are covered by oracle post here:
http://www.oracle.com/technetwork/testcontent/adfregioninteraction-15...

But scenario I want to discuss is:

Having taskflow that only has input field as common set and actions are on
parent or consuming taskflow. For e.g. we are developing a product that has
a generic taskflow that generates the UI component from XML files and does
UI level validations too. At any given time this taskflow does not know the
context in which it is used for. Consuming page is aware of the context and
has button as 'Submit' and what they need to do is get the values from the
input fields in consumed taskflow so that business validations can be
performed and have control on submit action.

Moreover this consuming page will be wrapped in taskflow and eventually be
part of web center app. This taskflow needs to be independent and should
not be dependent on final jspx page/pageDef to do be aware of any details
of taskflow it is consuming.

I approached the issue with getting the handle of DCBindingContainer and
finally getting handle of Iterator and attribute bindings in it.

In the last few implementations we did, this pattern was very much used and
I want to process if this could be listed use pattern and support can be
provided by hiding plumbing details. Few things that is different here is:

1. Generic taskflow does not have a event raiser except when values for
input are changed. Raising events could  for all inputs could be expensive.
2. Raising event was also thought with respect to security issues as it may
have sensitive personal data.
3. They are functionally dependent on consuming taskflow to get their
existence and meaning.

I would appreciate if we could figure its feasibility.

Regards
Amit

As an alternative you might be interested in the "Chaperone" technique
as blogged here:

http://one-size-doesnt-fit-all.blogspot.com.au/2010/09/master-child-b...

This allows child-to-parent communications without the need for
contextual events.  The concept works by the child BTF defining a
parameter based on an interface (the contract), and the caller supplying
a concrete implementation where the real work occurs.  It has the added
advantage it's easier to debug than contextual events as everything
happens in code.

Note the technique allows communication up the chain (child to parent),
not the other way around.  In turn be careful to understand which scoped
beans the concrete class has access to at runtime (ie. parent vs child
pageFlowScope beans).

Regards,

CM.

On 8/02/12 1:19 AM, Amit Seth wrote:

the problem I see with your approach is that you are not establishing
a contract but base your work on the assumption that the calling page
knows about the iterator and attribute names of the current page
fragment shown in the task flow.

Instead I suggest to define a contract as Chris suggests. Its the same
pattern that the Dynamic Tab Shell template uses to allow child
regions to open/close and modify tabs in a template. Have a look at
http://www.oracle.com/technetwork/developer-tools/adf/learnmore/94-ta...
to get a use case other than tab shell template for this. If you build
child task flows based on task flow templates, so that the input
parameter (the contract) gets implemented automatically, then you have
a pattern.

To answer your question: IMO, your approach doesn't make a good
candidate for a pattern

Frank

Hi,

Thanks Chris, I went through the 'Chaperone' technique and my approach was
a bit similar in way that in Child Taskflow I provided a class that needs
to be extended.. but user needs to set one id for the taskflow so that I
get handle for it.

Frank,
thanks for your response. I will go through the pdf link provided and will
try see to modify my code to establish the contract as stated by you.

Thank you all.
Amit

On Thu, Feb 9, 2012 at 9:03 AM, fnimphiu <frank.nimph...@googlemail.com>wrote: