Single page versus multi-page application?
Some people build a single-page application in which panels are replaced
dynamically. With this approach, the single page is analogous to a
Swing JFrame, to whom components are added and removed (or made visible
or invisible as needed).
Many people prefer to have separate pages for different functionality --
and this is necessary if the user is to be able to bookmark several
different pages. To do this, many people use markup inheritance, in
which sub-pages inherit from the base page, and the sub-page mark-up is
combined with the base-page mark-up. (Though it is to be generalized in
the future, I believe currently there can be only a single place in the
base page where the sub-page's components can go.)
I prefer to use a base page which contains one or more panels to be
defined by the sub-pages, via abstract panel-creation methods called by
the base page. However, Wicket convention is to add components in the
page constructor, and calling an overridden method from a constructor is
bad. (The overridden method will not be able to use anything set up in
the sub-page's constructor, due to the order in which constructors are
called.) I solve this problem by making my base pages inherit from the
following:
public class DelayedAssemblyWebPage extends WebPage {
protected boolean componentsAssembled = false;
@Override
protected void onBeforeRender() {
if ( !componentsAssembled ) {
try {
assembleComponents();
componentsAssembled = true;
} catch (Exception e) {
throw new RuntimeException(e);
}
}
super.onBeforeRender();
}
abstract protected void assembleComponents() throws Exception {}
}
So my application base page would look something like this:
public class MyApplicationBasePage extends DelayedAssemblyWebPage {
protected void assembleComponents() throws Exception {
// Add some components.
// Panels to be defined in subclasses are added
// by calling:
//
// add( createPanel_A("a_wicket_id") );
//
// and
//
// add( createPanel_B("some_other_wicket_id") );
}
abstract protected Panel createPanel_A( String panelWicketID );
abstract protected Panel createPanel_B( String panelWicketID );
}
Concrete child pages would look something like this:
public class OneConcreteChildPage extends MyApplicationBasePage {
protected Panel createPanel_A( String panelWicketID ) {
return new WhateverPanel(panelWicketID,...);
}
protected Panel createPanel_B( String panelWicketID ) {
return new SomeOtherPanelType(panelWicketID, ...);
}
}
This can be generalized in that the application base page can have
however many component-defining abstract methods you please.
Furthermore, one can generalize this to a page hierarchy of any depth,
since a semi-base page can define additional abstract methods to be
called by its implementation of createPanel_A() or createPanel_B().
-Frank
-----Original Message-----
From: nino martinez wael [mailto:nino.martinez.w...@gmail.com]
Sent: Friday, February 26, 2010 7:50 AM
To: users@wicket.apache.org
Subject: Re: UI Layout
For me it seems it would very confusing if I only had one page. I'd
prefer
pages that are target against their specific functionality, keeping code
simpler. I'd still be using panels though, giving the benefit of ajax,
role
base plus all the other stuff.
my 2 centavos
-Nino
2010/2/26 Josh Kamau <joshnet2...@gmail.com>
> Wicket offers high level of flexibility when it comes to page layout.
So i
> ask, what are the best practices? is it ok if i use panels only and
one
> main
> layout page?
>
> Kind regards
>
> Josh.
>
