Dynamic UI Layout

2010-10-10 Thread Josh Kamau
Hi guys;

I am trying to create a dynamic layout for bean fields. The fields could
have the labels on top or on the side, The layout could be single column or
multiple columns. Any idea on how to do this? I am thinking of using a table
and use column span for multiple column. Any suggestions will be welcome.

kind regards.
Josh


Re: Dynamic UI Layout

2010-10-10 Thread meduolis

You can use ListView's:

https://cwiki.apache.org/WICKET/forms-with-dynamic-elements.html
https://cwiki.apache.org/WICKET/page-with-dynamic-components.html
https://cwiki.apache.org/WICKET/create-dynamic-markup-hierarchies-using-panels.html
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Dynamic-UI-Layout-tp2970085p2970123.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-07-14 Thread armandoxxx

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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-07-14 Thread Arjun Dhar

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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-07-14 Thread armandoxxx

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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-07-14 Thread Ernesto Reinaldo Barreiro
why not use repeaters for things you don't know in advance?

Ernesto

On Wed, Jul 14, 2010 at 12:09 PM, armandoxxx armando@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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-07-14 Thread armandoxxx

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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-07-14 Thread Ernesto Reinaldo Barreiro
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 armando@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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-07-14 Thread armandoxxx

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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-07-14 Thread Arjun Dhar

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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-07-14 Thread armandoxxx

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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Jquery UI Layout

2010-05-21 Thread Josh Kamau
Hi WiQuery Team,

Do you have any plans of including Jquery UI Layout in wiQuery? I urgently
need it.

regards.

Josh.


Re: Jquery UI Layout

2010-05-21 Thread Josh Kamau
Still on WiQuery,

I would also be glad if you let me know how to wrap up any JQuery plugin as
a wiquery component.

Regards.

On Fri, May 21, 2010 at 9:07 AM, Josh Kamau joshnet2...@gmail.com wrote:

 Hi WiQuery Team,

 Do you have any plans of including Jquery UI Layout in wiQuery? I urgently
 need it.

 regards.

 Josh.



Re: Jquery UI Layout

2010-05-21 Thread julien roche AKA indiana_jules
Hi,

All our jQuery UI components and behaviors were made as wiQuery plugins. You
can take a look on the code in the svn. You have got too an example for the
qTip plugin:
http://groups.google.com/group/wiquery/browse_thread/thread/119255ce1db56101/7b36b3cc2ed957a0?lnk=gstq=tooltip#7b36b3cc2ed957a0

Most, you can found two base of implementations in the svn (there were used
for a presentation):
http://code.google.com/p/wiquery/source/browse/#svn/examples/wiquery-presentation-examples/src/main/java/org/odlabs/wiquery/presentation/examples/ui/layout
http://code.google.com/p/wiquery/source/browse/#svn/examples/wiquery-presentation-examples/src/main/java/org/odlabs/wiquery/presentation/examples/scrumdashboard

If you want, you can fork our github wiquery plugin project (
http://github.com/lionelarmanet/wiquery-plugin) and you can upload your
implementation of the UI Layout

Cheers

Julien Roche


On Fri, May 21, 2010 at 8:25 AM, Josh Kamau joshnet2...@gmail.com wrote:

 Still on WiQuery,

 I would also be glad if you let me know how to wrap up any JQuery plugin as
 a wiquery component.

 Regards.

 On Fri, May 21, 2010 at 9:07 AM, Josh Kamau joshnet2...@gmail.com wrote:

  Hi WiQuery Team,
 
  Do you have any plans of including Jquery UI Layout in wiQuery? I
 urgently
  need it.
 
  regards.
 
  Josh.
 



Re: Jquery UI Layout

2010-05-21 Thread Ernesto Reinaldo Barreiro
Hi Josh,

I have adapted (and extended a bit) the UI Layaout plugin Julien
mentioned and released it in [1]. You can find examples on how to use
it at [2]. The same component can be used to build full page layouts
or to make a given DIV into a Layout.

Best,

Ernesto

References

1-http://code.google.com/p/wiquery-plugins/source/browse/#svn/trunk/wiquery-plugins/other-plugins/src/main/java/org/odlabs/wiquery/plugin/layout
2-http://code.google.com/p/wiquery-plugins/source/browse/#svn/trunk/wiquery-plugins/other-plugins/src/main/java/org/odlabs/wiquery/plugin/layout/test

On Fri, May 21, 2010 at 8:07 AM, Josh Kamau joshnet2...@gmail.com wrote:
 Hi WiQuery Team,

 Do you have any plans of including Jquery UI Layout in wiQuery? I urgently
 need it.

 regards.

 Josh.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-03-08 Thread Juha Palomäki
 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



Re: UI Layout

2010-03-08 Thread Juha Palomäki
) );

    }



    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



Re: UI Layout

2010-03-08 Thread Marek Šabo
 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


   


-- 
Marek Šabo
Server Manager
Club SU CVUT Buben
Bubenečská Kolej (421)
XMPP: zeratul...@gmail.com


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: UI Layout

2010-03-05 Thread nino martinez wael
+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.

 




Re: UI Layout

2010-03-03 Thread Stefan Jozsa
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 joshnet2...@gmail.com wrote:

 From: Josh Kamau joshnet2...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



UI Layout

2010-02-26 Thread Josh Kamau
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

2010-02-26 Thread nino martinez wael
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.



RE: UI Layout

2010-02-26 Thread Frank Silbermann
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.

 



Re: UI Layout

2010-02-26 Thread Martin Makundi
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 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