calling a child page component from parent page component in wicket

I have a problem which I tried to explained in the Image.I hope that will help all to understand what I need.

My Base Page is like this (menuNavPanel is the tree panel):

<div class="colContainer">
    <div class="leftColumn" >
        <div wicket:id="menuNavPanel"></div>
    </div>
    <div class="rightColumn">
        <wicket:child/>
    </div>
</div>

And Ny BIA Page which is a child of Base Page is like this:

 <wicket:extend>
   <div wicket:id="bodyPanel"></div>
 </wicket:extend>

in my Tree Panel, when I click on a node the code is this:

    @Override
        protected void onNodeLinkClicked(AjaxRequestTarget target, TreeNode node) {
            super.onNodeLinkClicked(ta开发者_StackOverflowrget, node);
            DefaultMutableTreeNode treeNode = (DefaultMutableTreeNode)node;
            Unit unitObject =(Unit) treeNode.getUserObject();

           // I want to call bodyPanel fo child page passing the  unitObject param


        }

Now, How can I call bodyPanel fo child page passing the unitObject param from the tree panel of the parent page?

Am I been able to express my problem? Hoping to get some help :)

Instead of doing the override method, upgrade to Wicket 1.5 and utilize the new event bus to communicate between your components. You can create a custom, type-safe, event that is specific to your component's use case: for example "ItemAddedToShoppingCart" or "GlobalThermoNuclearWarStarted".

The linked article in the 1.5 migration guide provides enough information on how to set up things.

I'm not sure I understand que question correctly. Your BasePage defines a left column with the TreePanel and lets subclasses expand themselves inside the right column div. You usually put a BodyPanel inside BasePages's subclasses. And now you want to invoke a BodyPanel's method on some event on the TreePanel.

You could do it with an overridable method on BasePage, which would be called in TreePanel through getPage(). Your child pages would override that method, and its implementation would call the BodyPanel they're holding.

public class BasePage ... {
    // Hook 
    public void treePanelSelected(Object someObject) { }
    ...
}

public class ChildPage extends BasePage ... {

    BodyPanel bodyPanel;
    @Override
    public void treePanelSelected(Object someObject) { 
        bodyPanel.selectionChanged/(someObject);
    }
    ...
}


public class TreePanel ... { 

   ... 
    @Override
        protected void onNodeLinkClicked(AjaxRequestTarget target, TreeNode node) {
            super.onNodeLinkClicked(target, node);
            DefaultMutableTreeNode treeNode = (DefaultMutableTreeNode)node;
            Unit unitObject =(Unit) treeNode.getUserObject();

            ((BasePage)getPage()).treePanelSelected(unitObject);
        }
    }

From my ignorance on your specific needs and details of implementation, I don't see why is subclassing the BasePage necessary. You could add the BodyPanel right there in the BasePage and control it from the same class.

Thanks all, After reviewing all the nice options I finally opted out for the event bus way defined by martijn. What I did is I have created an event payload and connected the panels for the talking. I also needed to pass the selected Id / entity to the receiving panel.

Is there a way to set a compound property model of the receiving panel according to the model of the tree element so that I don't need to do the model manually ?

I did like this for the time being:

public class TreeNodeClickUpdate {

    private final AjaxRequestTarget target;

    private  final long selectedId;

    /**
     * Constructor
     *
     * @param target
     * @param selectedId
     */
    public TreeNodeClickUpdate(AjaxRequestTarget target, long selectedId)
    {
        this.target = target;
        this.selectedId = selectedId;
    }

    /** @return ajax request target */
    public AjaxRequestTarget getTarget()
    {
        return target;
    }

    public long getSelectedId() {
        return selectedId;
    }
 }

On the sender side I've done like this:

  send(getPage(), Broadcast.BREADTH,
        new TreeNodeClickUpdate(target, unitObject.getId()));

And on the receiving end I got it like this:

           @Override
           public void onEvent(IEvent<?> event) {
              super.onEvent(event);

             if (event.getPayload() instanceof TreeNodeClickUpdate)
            {
              TreeNodeClickUpdate update = (TreeNodeClickUpdate)event.getPayload();
              setSelectedId(update.getSelectedId()); //sets to id field of panel
              update.getTarget().add(this);
            }


          }

and for just as an example in my receiving panel, to get the value I have created a label like this:

  label = new Label("label",new PropertyModel<BiaHomePanel>(this,"selectedId"));

Later, in reality I want to get information from the entity and show in form. Is there a nice way to pass models in a better way or I should pass as a parameter in event payload.

There are two ways to do this. One is cleaner, but requires more code. The other is quick and dirty.

Method 1: (Good)

Since your parent page is being extended, you can provide an abstract method in the parent like

protected abstract WebMarkupContainer getBodyPanel();

that is implemented in your child page and returns the appropriate panel. Then, you can call that method from the panel in your parent page. This is similar to the overrideable method suggested by the other user.

Method 2: (Bad)

The Wicket Component Hierarchy is shared between the parent and child pages. So, if you make sure that your bodyPanel has a unique wicketId and is added directly to the root of the page, you can probably just call

get("bodyPanelId");

and it will return the proper panel.

When I was facing the problem, I thought of two ways to solve this (pre 1.5):

a) implement a variation of the observer pattern to notify other component of events like outlined here: Realising complex cross-component ajax actions in wicket - The observer way

b) using wicket visitors to traverse the component tree doing the same.

I decided to go for variant a) but this introduces coupling from your component to your page-implementation which leads to problems when testing panels on their own. So maybe b) might be the better idea but since my application is running quite smoothly with a) implemented and the next big step will be switching over to 1.5 and the event bus, I haven't yet tried b).