I also like the approach of pushing every functionality in separate components (Panels), it gives me the flexibility of composing pages with any combination of this components. For instance, if I have Login functionality, I create the LoginPanel and LoginPage. This approach allows me to add other Panels (if needed) to LoginPage.
Regarding storing the primary model to the base page, I would suggest using a custom session for storing it. This way you can benefit from strongly typed objects and be able access it anywhere in your application. Alex Ned Collyer wrote: > > The system I'm building at the moment has almost everything pushed down > into components. Most of the functionality is achieved by a single base > page which takes a component in its constructor. > > For Bookmarkable pages, I extend this base page, and pass a component to > the super. > > How do _you_ separate concerns? Is there a best practice? > > A benefit of using a page is that it can be accessed with "getPage()" > regardless of how deep in the hierarchy you are... so I guess it could be > useful for storing the primary model for that section of the site. > > Anyway, I'm interested in hearing how others deal with Page vs Components, > and how they structure their applications. > > So many ways of skinning a cat :) > > Rgds > > Ned > -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20027716.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
