I am using annotation based approach which requires much less coding. Take at
these links: 
1) http://subject-ivity.blogspot.com/2008/11/wicket-ajax-event-updates.html
2)
http://techblog.molindo.at/2008/09/wicket-loose-coupling-of-componens-for-ajax-updates.html

Alex Objelean



John Armstrong-3 wrote:
> 
> Hi Wicketeers,
>    I've just started into using Ajax in my Wicket apps and somehow
> ended up using a specific pattern. My question is "Is this pattern the
> Wicket Way" and if not, what is the "Wicket Way".
> 
>    Situation:
>    The pages I am ajax enabling consist of many panels. Some panels
> have navigational elements that need to trigger changes in other
> panels at different levels of the heirachy.
> 
>    The Pattern
>    My pattern is to pass down the webpage to subsequent panels as
> required. At the mainpage level I have a swap routine for each panel
> that needs change via ajax.
> 
>    My code ends up looking like this :
> 
>    public class PublicBasePage extends WebPage {
>               public PublicBasePage(){
>                       PublicLeftNavPanel publicLeftNavPanel = new
> PublicLeftNavPanel("publicleftnavpanel",this);
>                       add(publicLeftNavPanel);
>                       ...
>                       ...
>               }
>               void swapMainContent(Panel thePanel,AjaxRequestTarget target){
>                       thePanel.setOutputMarkupId(true);
>                       centerBox.replaceWith(thePanel);
>                       if (target != null) {
>                     target.addComponent(thePanel);
>                       }
>                       centerBox = thePanel;
>               }
>               ... More of these swaps for each element in the page that is
> ajaxified. Could be abstracted a bit more
>                 ... I also have a version that works for the non-ajax
> case so it falls back cleanly
>       }
>       
>       --
>       public class PublicLeftNavPanel extends Panel {
>               public PublicLeftNavPanel(String id, final PublicBasePage 
> mainPage){
>                       super(id);
>                       AjaxFallbackLink residentialLink =  new 
> AjaxFallbackLink("residential")
> {
>                               @Override
>                               public void onClick(AjaxRequestTarget target) {
>                                       mainPage.swapMainContent(new
> PublicResidentialMainPanel("centerbox"),target);
>                               }
>                       };
>                       residentialLink.setAutoEnable(true);
>                       add(residentialLink);
>                       ... More of these ajaxlinks for each link element in 
> the navigation bar
>               }
>       }
>       
>       So, what is happening is the navigation panel calls back into the
> webpage to do the swap required in lower level panels that live in
> different branches of the tree.
>       
>       It works but doesn't feel right and in all my googling I could not
> find a clear answer on specifically what to do when you have
> disconnected panels and one panel needs to trigger an update in the
> other one. I imagine its obvious so my apologies.
>       
>       I did find a link to "Loose coupling"
> (http://techblog.molindo.at/2008/09/wicket-loose-coupling-of-componens-for-ajax-updates.html)
> but that seemed a bit of a ways to go to accomplish the task (although
> very elegant).
>       
>       Thanks for setting me straight before I go too far with this,
>       John-
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Ajax-Panal-update-pattern--tp24483500p24484436.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to