Re: 1:1-translation from html [was: Wicket vs. ZK]
valid criticism, i think. but the truly powerful thing about wicket is that there's really nothing special about any of these components. if you want a more powerful or more generalized component for dealing with choices, write it. if people like the improvements enough, it can move into extensions or even core. btw, the limitations inherent in some of these components are due almost entirely to time constraints. i was aware of, but frankly never cared about the limitations you're describing, so i never considered addressing them. but as wicket continues to grow in popularity, the time to rework some of my/our early-day shortcuts be just around the corner. i think it's valuable to rework things, even core things when there is a real need or lacking. jon Jan Kriesten wrote: > > > 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] > > > -- View this message in context: http://www.nabble.com/Wicket-vs.-ZK-tf4276516.html#a12230024 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: 1:1-translation from html [was: Wicket vs. ZK]
> 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. It's certainly not a perfect framework, and we need people like you to point that out and come up with suggestions for improvement :) > 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... Tbh, I don't know these components well enough to have a strong opinion about it. What you can try though, is develop an alternative that you think would be better. Such a component could be placed in a wicket-stuff project (like minis), but if many people think this is a great improvement, it could even replace core components. Cheers, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1:1-translation from html [was: Wicket vs. ZK]
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]
