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
