> However, I discovered a navigation issue and am considering adding the > Breadcrumb feature to this site. Unfortunately, it looks like the > breadcrumb control uses Panels instead of pages. So it looks like I > need to switch everything from being page-based to panel-based. Of > course, doing that will take some time, but it isn't the end of the > world.
The bread crumbs component should be generic enough to be usable for a more page based approach. At least, that's the idea. What we need though is people - like you for instance - who need this in such a context and build support for it and validate it by using it in a real application (aka eating your own dogfood) :) Also, it might very well turn out that it is easier to roll your own component that does exactly what you want. That said, it is something that a lot of people want to do, so anyone interested in it, please pick it up and improve it (or write a new, better one) so that we have a good solution for both page based and panel based approaches. > So, I guess I'm just wondering, what do the rest of you end up doing? > Do you find that most of your "web pages" are actually Panels in a > single Page? Or are your sites built using many Pages? Or is it > somewhere in between? I'm just curious if there is a majority one way > or the other and if there are any strong reasons for one approach over > the other. The project that I'm working on is primarily panel based. We only have a couple of pages, but most works using panel replacements. Not sure what is best as both have pros and cons. What I like about panel replacements is that it promotes reuse. It's also very flexible. The app I'm working on is pretty generic, with 'business components' that plug in the system and provide their own interface (and e.g. contributions to the bread crumbs model). The downside of this aproach is that things can get complex; when you have errors it is sometimes hard to track down exactly what/ where/ how, and getting an overview of what your page will look like in the end is either a lot of work maintaining preview sections, or just a lot of guessing :) With a page based aproach it is easier to keep the overview, and it will be easier to track down issues. And - like you said - bookmarkability (and working with stateless pages) is way easier. The downside is that it is not as flexible, and you'll have to watch out for code duplication. Also, when you don't care much about bookmarkability, I find it a slightly bloated programming model, as you'lll have to write plumbing code just to stay on pages. Imho, a mixed aproach is always an option, but if you need/ want to choose between the two, probably the most important questions are whether you need many areas to be bookmarkable (yes -> page based), you work with separate designers (yes -> both are ok, but page based probably easier) and whether working page based provides you with enough flexibility (in other words: do you know all the functionality upfront and can you code it simply by providing a couple of pages for it). It would be interesting to read what the experience of other's is in this respect. Cheers, Eelco ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
