+1 for multiple page + abstract base page..
2010/2/26 Frank Silbermann <frank.silberm...@fedex.com>
> 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.
>
> >
>
>
