Design Opinions regarding ViewController projects interacting together

Question

Using JDeveloper 11.1.1.4.0
I have a set of ViewController (VC) projects that are deployed as ADF Library jars separately. These projects are consumed in a single Project which uses the taskflows in the modularized projects.
Now a new requirement was introduced where i need to have two libraries consume each other.
VC1 = ViewController1 (ViewController1ADFLibrary.jar)
VC2 = ViewController2 (ViewController2ADFLibrary.jar)
So, when VC1 consume VC2, VC1 inherits VC2's classpath including its Databindings.cpx.
What happens is that when VC2 consumes VC1 as well, VC2 gets a runtime exception saying that there are 2 Databindings.cpx in its classpath.
I know this is a classic case of library dependency, and we've been thinking that the only way to solve it is via contextual events or launching a url call for both of them to communicate. But i'm wondering if there is a much better approach to take when such requirements comes into the picture.
-Marvin

Answer 1

I briefly went through the blog and this is what i grasp real quick hehe, and forgive me if i missed something critical =)
The approach is basically using a bean as reference to trigger both regions since they share the same bean reference.
In this approach, it will even be cooler if the buttons using the event has a rendered property to only show up if the bean(interface) is not null that way it has even lesser coupling.
But a small drawback here is that you're introducing a specific interface in the taskflow input parameters that is meant for such use case only.
While this approach has that little documentation to keep things straight in the specification of the taskflow, it does indeed relieve the situation with the use of the binding layer for the event mapping.
The real complexity comes in when two regions needs to ppr specific areas of each other's region, which in my opinion, is a design flaw to begin with as to why bother separating them for the complexity being introduced.
I guess, in that sense, it is always better to start with simple code even if it means being repeated at the beginning before wrapping it to its full reusable state since adding a lot of condition in a reusable component is harder to maintain in the long run.
In your example, you are tapping more on the simplicity of using java beans as reference oppose to event handling, which really gives more control in my opinion and also easier to document.
Thanks for the article on the Chaperone Chris, interesting read for my Saturday.