hi eelco, > I agree: especially if you break your application up in many panels, > it can be hard to keep an overview. So sometimes, there is something > to say for following a more page based approach in favor of > reusability. However, part of the argument still holds as even broken > up in panels, you still don't have to deal with loops, conditionals, > etc in your markup. It should still pretty much be a 1-1 translation, > where the only extra thing you do is break it up in smaller pieces.
i'm a fan of wicket, but some 1:1-translations are not that easy to accomplish. in fact, select, choices (and radio) are still a weak part in wicket (imho). there are many classes to deal with them, but most aren't customizable enough and/or require different markup (span instead of select) as the designer would put in. especially for radiogroups or checkboxmulti it would be much easier to not have have a surrounding element, also options should be customizable from the html... i know there is a Select-class in extensions, but that isn't a real advance over the existing classes in core. don't get me wrong - you can almost do everything you want with the given function set. but it's sometimes hard to resolve the designers view of the page in this respect. best regards, --- jan. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
