|ichoicerenderer exists for two reasons. one is to generate an id so that a specific imodel can be picked out of a list of imodels. two so that you can convert model object into some user string to display to the user. NEITHER |of these apply to radio, so radio will not have an ichoicerenderer. I see your point, and am aware that it's just not the logical place to implement it. I guess RadioGroup/checkgroup would be a better place?
|no it wouldnt be a better place. |yes, you are not meant to have control over it - it is an implementation detail of that component. Well again correct, radiogroup/checkgroup seems a better place. I might have been a little slow here. |once again, no. the choice renderer simply doesnt apply to these components. Come on, a little better would it be. Since radiogroup contains radios. So it is a kind of container. But in the sense that it arent just possible to implement the change without some changes youre right. And in fact i guess if we change it too much we would just end up with the RadioChoice component. Which already takes an ichoicerenderer. I am using Jmeter, but the whole trouble originates by that data are changeing. And in production it would not make sense for it to remain stable, but some of it are stable and this is what we are wanting to test. Currently we have agreed that we only run one test (orginal we had 15 individual tests) which needs to be recreated / or manipulated with the correct radio id's. Im wondering since no one else seems to have these problems, they have either not used the radio / check components or does not performance test this way? Is this an uncommon way to performance test over time? regards Nino ________________________________ Fra: [EMAIL PROTECTED] på vegne af Igor Vaynberg Sendt: ma 02-04-2007 20:13 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? On 4/2/07, Nino Wael <[EMAIL PROTECTED]> wrote: |ichoicerenderer exists for two reasons. one is to generate an id so that a specific imodel can be picked out of a list of imodels. two so that you can convert model object into some user string to display to the user. NEITHER |of these apply to radio, so radio will not have an ichoicerenderer. I see your point, and am aware that it's just not the logical place to implement it. I guess RadioGroup/checkgroup would be a better place? no it wouldnt be a better place. |yes, you are not meant to have control over it - it is an implementation detail of that component. Well again correct, radiogroup/checkgroup seems a better place. I might have been a little slow here. once again, no. the choice renderer simply doesnt apply to these components. perhaps what you should work on is running jmeter, or whatever you use, over a stable dataset. the way these components work are deterministic - so same test over same data should produce same html -igor ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user