ADF Region Interaction - New Pattern - Parent page extracting values from consumed region.

[Amit Seth]

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-155145.html

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

[Chris Muir]

Hi 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-btf-chaperone-contextual.html

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.

> --
> You received this message because you are subscribed to the ADF
> Enterprise Methodology Group
> (http://groups.google.com/group/adf-methodology). To unsubscribe send
> email to adf-methodolo...@googlegroups.com
>
> All content to the ADF EMG lies under the Creative Commons Attribution
> 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).
> Any content sourced must be attributed back to the ADF EMG with a link
> to the Google Group (http://groups.google.com/group/adf-methodology).

[fnimphiu]

Amit,

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-taskflow-return-exit-1474324.pdf
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

[Amit Seth]

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