This content has been marked as final. Show 2 replies
why not passing a managed bean reference as an input parameter to the bounded task flow. This way the task flow calls the methods exposed on that bean to invoke an action on the parent view. This is how the dynamic tab shell template does it allowing bounded task flows in regions to open new tabs. Your approach invokes a region navigation listener, which obviously works as well. According to the RegionNavigationListener doc this also is expected:
A RegionNavigationEvent is generated when the fragment being displayed by a region is changed. The viewId of the old fragment, and the viewId of the new fragment is provided by this event. Sometimes, the old viewId and the new viewId might be the same (if the UIXRegion.refresh(javax.faces.context.FacesContext) method is called).
However, if you just pass in arbitrary viewIds then the region is out of synch with the actual task flow state. This is not a problem in my opinion as long as you don't care for the correct viewId (e.g. if there is no logic that needs to be executed upon view Id change from view A to view B). Alternatively however you can read the current view Id from teh controller context and just "mimic" a region refresh by posting the current view id with the queued event. So the only thing I guess like more about passing an input argument into a bounded task flow - compared to your approach - is that this is better readable as a contract between task flow provider and consumer. Consumers of your task flow actually need to know that there is a navigation event they need to listen for (which also might be okay for dependent task flows that are always deployed and used in conjunction).
I would think that use case matters and if this is what makes it work then okay.
Edited by: Frank Nimphius on Apr 25, 2012 8:45 AM
Thanks for response.
To tell you truth, I thought about it, but there were a few things that confused me.
Can you please clarify them for me?
1. First of all, parent task flow's managed bean (which should be an input param. to the BTF) are request scoped.
B.T.F. who needs to use that reference are hosted to embedded af:popup, (so, popup is a part of the "parent" task flow View fragment, as usual).
Now, if I pass current (request scoped !) managed bean instance as param when popup fetches, would not it be obsolete when the time comes to use him ?
Keep in mind that BTF popup are modeless, so user can play with popup's background, thus changing parent t.f. backing bean instance.
Or I am wrong ?
Have you one example how that one param should be defined and passed ?
2. Second, by passing managed bean as parameter and using one of his method in BTF, by my opinion,also makes BTF to be dependent on specific managed bean implementation. Thus way, I must tell to t.f. consumers that they must provide such one class in order to t.f. works as expected.
Or I am wrong ? (Thinking further about this...maybe t.f. can accept Java interface as input param, and just call that interface method ? That way, the real parameter (backing bean from parent t.f.) should implement that interface. Will this works ?!?) Anyway, the first question still confuses me...
- Thanks in advance !
Frank Nimphius wrote:Edited by: Cvele_new_account on Apr 25, 2012 3:05 AM
why not passing a managed bean reference as an input parameter to the bounded task flow. This way the task flow calls the methods exposed on that bean to invoke an action on the parent view. This is how the dynamic tab shell template does it allowing bounded task flows in regions to open new tabs.
Edited by: Cvele_new_account on Apr 25, 2012 6:22 AM