Re: Pages or components... how do u decide?
Hello Ned, I am using BreadCrumbPanels, and on a BreadCrumbLink, i wanted to pass a parameter but looks like I cannot instantiate the custom constructor of the panel in this case. Please advise. :( //Naveen On Tue, Oct 21, 2008 at 6:19 PM, Ned Collyer [EMAIL PROTECTED] wrote: Their constructor :) Nav Che wrote: Ned, But then how do u pass parameters across the panels??? //nav -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20100652.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]
Re: Pages or components... how do u decide?
Isn't there already another thread about this question started by you? On Wed, Oct 22, 2008 at 9:27 AM, Nav Che [EMAIL PROTECTED] wrote: Hello Ned, I am using BreadCrumbPanels, and on a BreadCrumbLink, i wanted to pass a parameter but looks like I cannot instantiate the custom constructor of the panel in this case. Please advise. :( //Naveen On Tue, Oct 21, 2008 at 6:19 PM, Ned Collyer [EMAIL PROTECTED] wrote: Their constructor :) Nav Che wrote: Ned, But then how do u pass parameters across the panels??? //nav -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20100652.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pages or components... how do u decide?
Ned, But then how do u pass parameters across the panels??? //nav On Sun, Oct 19, 2008 at 5:55 PM, Ned Collyer [EMAIL PROTECTED] wrote: I use markup inheritance for some pages, but I try to avoid making new pages (after all, what do they give you that a panel does not (other than an URL)?) I do use markup inheritance for components A LOT!! jwcarman wrote: Are you using one page and just passing in your content component? Are you not using markup inheritance? On Thu, Oct 16, 2008 at 5:16 PM, Ned Collyer [EMAIL PROTECTED] 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--tp20016807p20016807.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20060673.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]
Re: Pages or components... how do u decide?
Their constructor :) Nav Che wrote: Ned, But then how do u pass parameters across the panels??? //nav -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20100652.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]
Re: Pages or components... how do u decide?
A URL is quite a strong argument for using pages. With the wicket-annotations project its dead-easy to make pages bookmarkable, just add @MountPath(path=/path/to/page). Jörn On Sun, Oct 19, 2008 at 11:55 PM, Ned Collyer [EMAIL PROTECTED] wrote: I use markup inheritance for some pages, but I try to avoid making new pages (after all, what do they give you that a panel does not (other than an URL)?) I do use markup inheritance for components A LOT!! jwcarman wrote: Are you using one page and just passing in your content component? Are you not using markup inheritance? On Thu, Oct 16, 2008 at 5:16 PM, Ned Collyer [EMAIL PROTECTED] 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--tp20016807p20016807.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20060673.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]
Re: Pages or components... how do u decide?
I use those annotations - they are awesome :) If you could annotate a panel to be bookmarkable.. that'd be interesting. So the panel COULD be embeded into other components, or used standalone as a page. Currently I achieve this by creating a new page class which instantiates and passes the panel to the super. Anyway, i thought it was an interesting thing to discuss. Jörn Zaefferer-2 wrote: A URL is quite a strong argument for using pages. With the wicket-annotations project its dead-easy to make pages bookmarkable, just add @MountPath(path=/path/to/page). Jörn -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20065174.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]
Re: Pages or components... how do u decide?
The only markup difference between pages and panels for me is that panels use wicket:panel and pages use wicket:extend. Making that the same, I'd prefer wicket:extend, would make it even easier to switch from a page to a panel and back. Jörn On Mon, Oct 20, 2008 at 10:22 AM, Ned Collyer [EMAIL PROTECTED] wrote: I use those annotations - they are awesome :) If you could annotate a panel to be bookmarkable.. that'd be interesting. So the panel COULD be embeded into other components, or used standalone as a page. Currently I achieve this by creating a new page class which instantiates and passes the panel to the super. Anyway, i thought it was an interesting thing to discuss. Jörn Zaefferer-2 wrote: A URL is quite a strong argument for using pages. With the wicket-annotations project its dead-easy to make pages bookmarkable, just add @MountPath(path=/path/to/page). Jörn -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20065174.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]
Re: Pages or components... how do u decide?
I use markup inheritance for some pages, but I try to avoid making new pages (after all, what do they give you that a panel does not (other than an URL)?) I do use markup inheritance for components A LOT!! jwcarman wrote: Are you using one page and just passing in your content component? Are you not using markup inheritance? On Thu, Oct 16, 2008 at 5:16 PM, Ned Collyer [EMAIL PROTECTED] 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--tp20016807p20016807.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20060673.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]
Re: Pages or components... how do u decide?
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]
Re: Pages or components... how do u decide?
Of topic but important nevertheless: About the only object you ever want to put in the session IMHO is the logged in user and its credentials. Even if you have a very small site with only one important model you should not put it in the session. There are 2 problems with this approach: - Technically you get problems because access to the session is not thread safe. - Usability suffers because the user can no longer have multiple tabs open in the same site and try out different things. Well, ok, /sometimes/ you want to prevent the latter to keep things simple for the user. A shopping cart is probably the best example. Regards, Erik. Alex Objelean wrote: 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 -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pages or components... how do u decide?
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--tp20016807p20016807.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]
Re: Pages or components... how do u decide?
Are you using one page and just passing in your content component? Are you not using markup inheritance? On Thu, Oct 16, 2008 at 5:16 PM, Ned Collyer [EMAIL PROTECTED] 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--tp20016807p20016807.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]