Enterprise Client Community

Hi community,

I've defined a page with contains a row with a button and rowinclude which contains another page.
Is there a way to trigger a method within the rowincluded page from the surrounded pages button?
I know the content / reference replace property, but I didn't find a way to inject a callback method
to the included page to delegate events!
The only programatically way I know would be to use the observer pattern, so my rowincluded page listens
to actions of the surrounded page, but maybe theres another better way?

My intention:

I want to create a common interface for editing certain entities, so theres a static row for change,
save and delete buttons
For each entity theres a separate page which contains the individual field / Value pairs. I don't want
to generate this design dynamically, I use the paintarea container.
This entity detail page I include in the interface page via rowinclude. Now I when I press the save button
I have to delegate the action to the rowincluded page, the same for delete or change action.

maybe someone facing the same situation?

regards
Markus

...so there is the necessity to talk between an outside page and an inside page. Each one having its own managed beans on server side.

There are several way to do so, because this is "JSF freestyle area" now...

The way we typically solve this is by using a dispatcher to organize the beans taht are accessed by pages.

#{d.bean1}
#{d.bean2}

So both beans are coming from a central object, the dispatcher. This object can be either (a) "hard wired" (getBean1, getBean2), or (b) you use the Default/WorkpageDispatcher framework.

If (b) then each object may be derived from Default/WorkpageDisptachedBean, and you may access other objects living in the same dispatcher-scope by: getOwningDispatcher().getDisptacherBeean(Class).

There is documentation on this in the Developer's Guide.

Now it's up to you to interconnect these instances. Of course if you want to have a certain level of abstraction you may use the observer pattern, so that the outside bean provides an interface to register listeners from the bean of the inside page.

Björn

Hi Björn,

sorry for the delayed answer, but I get stucked with other things.
I tried to build a connection between the workpage and the rowincluded workpage, with helper methods in the WorkpageDispatchedBean implemtation:

public UserDetailUI getUserDetailUI() {
return (UserDetailUI) getOwningDispatcher().getDispatchedBean(
UserDetailUI.class);
}

public EntityDetailUI getEntityDetailUI() {
return (EntityDetailUI) getOwningDispatcher().getDispatchedBean(
EntityDetailUI.class);
}

Now I create an instance of the Workpage(EntityDetailUI), in the constructor I call:

public EntityDetailUI(IWorkpageDispatcher dispatcher) {
super(dispatcher);
userDetailUI = getUserDetailUI();
}

userDetailUI is declared as private

When getUserDetailUI is called the constructor of UserDetailUI is called:
public UserDetailUI(IWorkpageDispatcher dispatcher) {
super(dispatcher);
// get wrapping entity detail UI bean
entityDetailUI = getEntityDetailUI();
}

Now the problem occurs when calling the statement getEntityDetailUI(), the constructor of EntityDetailUI is called again, this one calls the UserDetailUI and so on, till game over?!

It's a bit complicated to explain, sorry for that ...

Markus

...yes, the problem is: the bean is constructed, and then the dispatcher pushes the bean into its hashtable.

THis is the hashtable that is checked first when calling getOwningDispatcher().getDispatchedBean(...class...).

So, you are ending up in an never-ending (well Java tells you a certain end ;-)...) cycle.

You need to decouple the construction(s). I am sure you will find a way how to do this best for your scenario, now knowing what's happening in the background.

One way could be: you override the dispatcher's "get" method. This calls the original dispatcher's get method, and then takes the object and calls an init-method of the object. So you do a late initialitzation, that is triggered by your dispatcher implementation. Becaus the init() is called after the registration of the object in the dispatcher, the dependency problems should be solved. - I would call this pattern "dependency exjection". ;-)

Björn