One thing in the page vs panels discussion is also inheritance vs
composition. So do you construct the layout of the UI by inhering it
or do you take the mashup style -approach.
I've started thinking that it might be better to use panels for
functionality (for example CustomerEdit, CustomerAdd) and then use
some kind of page structure around those to control the navigation.
Something where you could have for example two completely different
navigation systems on the application at the same time.
br, Juha
On Mon, Mar 8, 2010 at 10:44 AM, Juha Palomäki <juha.palom...@gmail.com> wrote:
> Here's what we have been using for CRUD stuff:
>
> Domain:
> Customer
> - name : String
> - industry : String
> - primaryContact : Contact
>
> Contact
> - name : String
> - Address : String
> - Email: String
>
> Pages:
> CustomerBasePage (abstact)
> CustomerAddPage
> CustomerEditPage
> CustomerViewPage
>
> Panels:
> CustomerBasePanel
> CustomerEditPanel
> CustomerViewPanel
>
> ContactBasePanel
> ContactEditPanel
> ContactViewPanel
>
> Most of the service layer -references are on the page-level. For
> example pages take care of retrieving customer from DB and persisting
> changes. The panels just receive IModel<Customer>.
>
> There are separate pages for add and edit, because those operations
> need to be handled differently. On the other hand the same edit
> -panels are used for both add and edit.
>
> One page can then host multiple panels. For example the
> CustomerViewPage could also host OrderViewPanel.
>
> The base -level does not contain that much functionality in many
> cases, but we have localization stuff there. For example the
> CustomerEditPanel and CustomerAddPanel share most of field labels, so
> there are stored in CustomerBasePanel.xml
>
> This leads to quite many classes, but on the other hand the classes
> are simple and straightforward in most cases. I find it more easier to
> deal with many simple classes than with few complex. To manage all the
> classes, I prefer to use package structure like this:
>
> org.example.app.customer.web.page
> org.example.app.customer.web.panel
> org.example.app.customer.web.support (custom models and other
> "support" stuff goes here)
> org.example.app.order.web.page
> org.example.app.order.web.panel
> org.example.app.order.web.support
>
> However I must say that I'm not completely satisfied with this
> approach. For example with the pages we can't simply create a nice
> ajax tabpanel that would contain CustomerViewPage, OrdersViewPage and
> ContactsViewPage.
>
>
> br, Juha
>
>
> On Fri, Mar 5, 2010 at 1:41 PM, nino martinez wael
> <nino.martinez.w...@gmail.com> wrote:
>> +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.
>>>
>>> >
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
