|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
