You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Josh Kamau <jo...@gmail.com> on 2010/02/26 11:23:06 UTC
UI Layout
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.
Re: UI Layout
Posted by Arjun Dhar <dh...@yahoo.com>.
ok, so you mention "wicket:id" as if its some constant thing.
Conceptually a markup tahhed by wicket-id, is no less powerful than
injecting a scriptlet or any dynamic script you inject via JSP, PHP. Its
like a reference point/range.
Who says that anything between that wicket:id condemns you to the markup
there? Thats what components are for. There are plenty of bases level
components for you to choose, override and customize.
SO once we've go through inheritance, panels the 2% that us not
templatizable and falls under dynamic category will surely be replacable by
some component.
I'd recommend you read up on available components. I think this is an issue
of perception that anything between "wicket:id" is static!
Mabe Im wrong in understanding your real problem but I'd simply say there
isnt anything you can do with JSP, JSTL, PHP that you can do with wicket!
..ok a bold statement :p Guys mack me up! haha kidding.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288872.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by armandoxxx <ar...@dropchop.com>.
Hey all
I finally figured out how to do it ... yes it helped to use ListView but at
first I did not notice .setReuseItems(boolean) function ...
after reading this article
http://www.javaworld.com/javaworld/jw-07-2008/jw-07-wicket2.html?page=1
I figured out how to draw whatever I want into my "column" component !
Kind regards
Armando
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288897.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by armandoxxx <ar...@dropchop.com>.
Hey ..
10x for your reply ..
I tried what you suggested but it's not working ...and the way wicket works
of course not.. you need wicket:id in a markup and I don't want to write it
... cause I'll probably die before i cover all cases needed by customer...
but hey .. 10x again for tryin
Kind regards
Armando
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288714.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Hi Armando,
I mean make "custom-label-panel" a repeater so that you can
dynamically add anything you need.
Best,
Ernesto
On Wed, Jul 14, 2010 at 1:56 PM, armandoxxx <ar...@dropchop.com> wrote:
>
> hi ..
>
> can you explain what you mean, cause I'm not sure what you mean ...
>
> King regards
>
> Armando
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288618.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by armandoxxx <ar...@dropchop.com>.
hi ..
can you explain what you mean, cause I'm not sure what you mean ...
King regards
Armando
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288618.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
why not use repeaters for things you don't know in advance?
Ernesto
On Wed, Jul 14, 2010 at 12:09 PM, armandoxxx <ar...@dropchop.com> wrote:
>
> Hey ...
>
> 10x for fast reply ..
>
> I am considering inheritance cause many stuff will be reusable but I have a
> little tiny problem with my components and trying to figure it out ...
>
> let me try to show an example ....
>
> I have my custom component that shows news, labels etc. These news can be
> categorized, so my news component is used on a page to show different type
> of news (lets say .. I have 4 columns, and this component is used 4 times
> showing different category of news in each) so far so good .. The wicket way
> to do this is just use wicket:id tag wherever I want to show my news
> component .. BUT .. I have a little problem with this in real world and real
> application.
> My columns are just panels to hold my components and unfortunate enough, I
> as a developer, cannot hard code what components must be rendered in each
> column, cause there are so many possibilities. In one case editors will use
> 4 columns to show news, on second case they will only use 2 columns for news
> and 2 for banners and these cases go on and on and on .. never ending story
> .. so to do this dynamically I created layout with 4 columns and now I'm
> trying to render my components into that columns without specifying tags
> with wicket:id in every column and every possible case ...
>
> I thought that if I create my custom component with markup file .. and then
> add this component to my column in page would render my component .. but ..
> it's not :( ... so if someone can point me to the right direction with this
> case .. that would be something ...
>
> my custom label panel markup file:
>
> <wicket:panel>
> <p>
> This is a custom test label
> </p>
> </wicket:panel>
>
>
>
> java for adding my custom label panel:
>
>
> left.add(new CustomLabelPanel("custom-label-panel"));
>
>
> And of course this will not work since (as I wrote before)
> "custom-label-panel" is never defined in columns in my layout ..
> I guess you already figured out that I'm too lazy to put tags in for every
> possible case customer might come up with. So any help will be greatly
> appreciated.
>
> Kind regards
>
> Armando
>
>
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288518.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by armandoxxx <ar...@dropchop.com>.
Hey ...
10x for fast reply ..
I am considering inheritance cause many stuff will be reusable but I have a
little tiny problem with my components and trying to figure it out ...
let me try to show an example ....
I have my custom component that shows news, labels etc. These news can be
categorized, so my news component is used on a page to show different type
of news (lets say .. I have 4 columns, and this component is used 4 times
showing different category of news in each) so far so good .. The wicket way
to do this is just use wicket:id tag wherever I want to show my news
component .. BUT .. I have a little problem with this in real world and real
application.
My columns are just panels to hold my components and unfortunate enough, I
as a developer, cannot hard code what components must be rendered in each
column, cause there are so many possibilities. In one case editors will use
4 columns to show news, on second case they will only use 2 columns for news
and 2 for banners and these cases go on and on and on .. never ending story
.. so to do this dynamically I created layout with 4 columns and now I'm
trying to render my components into that columns without specifying tags
with wicket:id in every column and every possible case ...
I thought that if I create my custom component with markup file .. and then
add this component to my column in page would render my component .. but ..
it's not :( ... so if someone can point me to the right direction with this
case .. that would be something ...
my custom label panel markup file:
<wicket:panel>
<p>
This is a custom test label
</p>
</wicket:panel>
java for adding my custom label panel:
left.add(new CustomLabelPanel("custom-label-panel"));
And of course this will not work since (as I wrote before)
"custom-label-panel" is never defined in columns in my layout ..
I guess you already figured out that I'm too lazy to put tags in for every
possible case customer might come up with. So any help will be greatly
appreciated.
Kind regards
Armando
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288518.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by Arjun Dhar <dh...@yahoo.com>.
Hi bro,
so "I need to change page layout markup file( since markup files will have
my panels defines)"
1. Use Inheritance: What I like about inheritance is you can template and
further sub-template without a single line of Java (except for empty class
files to represent the page ..I have a solution for this also.. read on).
(There is some debate on improving inheritance
http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-td2278064.html#a2278064;
but lets skip that)
"layouts change just a little bit on every page, so having 100-200 different
layout files is crazy " -- With good designed templates this should be
avoidable. And if not, panels can be used.
2. "I need to change page layout markup file (since markup files will have
my panels defines)" -- So, you dont need to use PANEL's only. As explained
above I believe inheritance is powerful where there is a lot of common
stuff. The dynamic stuff like news, article, navigation are panels that too
embedded inside the template. So the combination should reduce your
combinatorial explosion!
3. Ah regarding Class files: Well this is something bothering me as well.
I'm looking at CGLIB byte code generation to read the file system for markup
files and auto generate java classes into the ClassLoader. So there is no
need to write dumb classes. ..but this is work in progress. Just sharing the
idea if anyone can beat me to it :)
Please note that Im relatively new to wicket too, but through my initial
frustrating experiences I learnt somethings that i hope will help you. If
not, am sure the more experienced guys here will be providing valuable
input.
-good luck!
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288432.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by armandoxxx <ar...@dropchop.com>.
Hi guys ...
I have the same little issue and don't know how to resolve this ...
I work on 2 really big projects
One is a newspaper web site and other is more of a b2b application.
So for newspaper web site, showing all kinds of news and stuff I'm trying
with 1 page approach.
Reasons:
- loads of sub pages in navigation (like 100 - 200 pages and counting) . so
making so many classes and markup is nonsense (or let's say .. I'd rather
SHOOT myself in a foot)
- layouts change just a little bit on every page, so having 100-200
different layout files is crazy
B2B application is not that complicated .. it has fixed number of pages and
several "billion" different components ..
When I was working with PHP, years ago, we had a simple framework for
creating our web pages. BUT the idea was a bit more simpler ...
We had a page layout with panels ( to say it the wicket way, cause we called
them placeholders) representing header, footer, and content columns. In
those panels we rendered different components (news, article, navigation ..)
.
We dynamically read from configuration what layout to use for a singe page
and what components to load to it's panels. We also made a simple managing
page, so it was possible to simply define everything there.
And now I have to do this in wicket. I need to change page layout markup
file( since markup files will have my panels defines). So if someone can
tell me how to do that, I would really appreciate it.
please note that I'm only starting to use wicket and consider me as a 2 week
wicket noob.
Kind regards
Armando
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288378.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by Marek Šabo <ms...@buk.cvut.cz>.
+1 on this. I've been experimenting with ajax navigation switching
panels representing actions and using pages as containers for all these
actions (e.g. module User has its page which has menu where are links to
various action panels).
So far works best for me from all approaches I've tried.
On 03/08/2010 11:01 AM, Juha Palomäki wrote:
> 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 <ju...@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
>> <ni...@gmail.com> wrote:
>>
>>> +1 for multiple page + abstract base page..
>>>
>>> 2010/2/26 Frank Silbermann <fr...@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.wael@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 <jo...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
Marek Šabo
Server Manager
Club SU CVUT Buben
Bubenečská Kolej (421)
XMPP: zeratul021@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by Juha Palomäki <ju...@gmail.com>.
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 <ju...@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
> <ni...@gmail.com> wrote:
>> +1 for multiple page + abstract base page..
>>
>> 2010/2/26 Frank Silbermann <fr...@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.wael@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 <jo...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by Juha Palomäki <ju...@gmail.com>.
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
<ni...@gmail.com> wrote:
> +1 for multiple page + abstract base page..
>
> 2010/2/26 Frank Silbermann <fr...@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.wael@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 <jo...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UI Layout
Posted by nino martinez wael <ni...@gmail.com>.
+1 for multiple page + abstract base page..
2010/2/26 Frank Silbermann <fr...@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.wael@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 <jo...@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.
>
> >
>
>
Re: UI Layout
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
Hi!
I would propose using mashup approach, it's more flexible you don't
need abstract factory methods for adding content:
http://code.google.com/p/wicket-mashup/
**
Martin
2010/2/26 Frank Silbermann <fr...@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.wael@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 <jo...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: UI Layout
Posted by Frank Silbermann <fr...@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.wael@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 <jo...@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.
>
Re: UI Layout
Posted by nino martinez wael <ni...@gmail.com>.
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 <jo...@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.
>
Re: UI Layout
Posted by Stefan Jozsa <st...@yahoo.com>.
Right now I'm developing a single-page-multi-panel application.
Had some issues regarding history (that is browser back/forward), but
succeeded to fix them using wicketstuff-ajaxhistory.
What I failed (not yet succeded ...) is related to
'deep links', that is to bookmarkable URLs.
All in all, an Ajax based approach seeems to be more promising
(on long term) than the classical multi-page based one.
Stefan
--- On Fri, 2/26/10, Josh Kamau <jo...@gmail.com> wrote:
> From: Josh Kamau <jo...@gmail.com>
> Subject: UI Layout
> To: users@wicket.apache.org
> Date: Friday, February 26, 2010, 12:23 PM
> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org