Re: [Wicket-user] Radio.getValue?
|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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
Hi Nino, Sorry I was not following this thread from the start - but recently I had some success using JMeter for testing a wicket application by using the regular expression support built into JMeter. My test script actually can use the wicket:id values and so far I'm getting good results. Let me know if you need more details. Thanks, Peter. On 4/3/07, Nino Wael [EMAIL PROTECTED] wrote: 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 - 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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
We also can test without trouble, as long as the underlying data does not change. I guess this depends on how the application are built. But if you have something to add, we have created an entry on the wiki please feel free to add stuff to it. http://cwiki.apache.org/WICKET/wicket-and-jmeter.html regards Nino Fra: [EMAIL PROTECTED] på vegne af Peter Thomas Sendt: ti 03-04-2007 10:43 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? Hi Nino, Sorry I was not following this thread from the start - but recently I had some success using JMeter for testing a wicket application by using the regular expression support built into JMeter. My test script actually can use the wicket:id values and so far I'm getting good results. Let me know if you need more details. Thanks, Peter. On 4/3/07, Nino Wael [EMAIL PROTECTED] wrote: 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 - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
Before wicket processing or after? the after processing you can see here: prod.jobindsats.dk a user case could be: 1. select starthjælp from the left menu(this brings you to our wicket application in the middle frame) 2. select databank radio 3. select the Tilbagefald radio 4. press the submit button called næste There are some further steps, but this should make you see what the trouble are with the radios, by selecting the tilbagefald radio you also submit the page(this populates the info field), after the submit of the page then the radios gets new numbers. I also have the jMeter testplan if you want to see it? Hmm, it might be easier if I just took a look at your script? Also I dont want you to put in too much work on this(theres no need for it, since customer has accepted to rebuild the test plan each time). regards Nino Fra: [EMAIL PROTECTED] på vegne af Peter Thomas Sendt: ti 03-04-2007 11:11 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? Ok, once I manage to get something on the wiki (hopefully soon), I'll notify the mailing list. Meanwhile Nino - if you can send me separately a couple of different samples of HTML of the page you are trying to test, I can have a look to see if I have a solution using JMeter. Thanks, Peter. On 4/3/07, Nino Wael [EMAIL PROTECTED] wrote: We also can test without trouble, as long as the underlying data does not change. I guess this depends on how the application are built. But if you have something to add, we have created an entry on the wiki please feel free to add stuff to it. http://cwiki.apache.org/WICKET/wicket-and-jmeter.html regards Nino Fra: [EMAIL PROTECTED] på vegne af Peter Thomas Sendt: ti 03-04-2007 10:43 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? Hi Nino, Sorry I was not following this thread from the start - but recently I had some success using JMeter for testing a wicket application by using the regular expression support built into JMeter. My test script actually can use the wicket:id values and so far I'm getting good results. Let me know if you need more details. Thanks, Peter. On 4/3/07, Nino Wael [EMAIL PROTECTED] wrote: 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 - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user winmail.dat- 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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
|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? |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. |why do people keep bring up arguments like this? it is very annoying. is it our fault that you are in this situation? you put yourself there. now you expect us to make our component worse for all our users so that you can get |out of a corner you painted yourself into? Hmmm, I did not mean to accuse you of being the one whose fault it was, I never talked of fault. I just said that it was a little late for our project to implement drastic changes, this has absolutely nothing to do with the wicket devs. Wheter I put myself in the situation or not, I guess can be discussed on a lot of levels. And no I did not see it comming that the radio, werent persistant in it's id's. I never expected you guys to do anything, how could I. Wicket are opensource:) And I did certinly not want or expect of you to make any part of wicket worse, that would be a really bad thing to do. I just wanted to point out that there was something that was less that optimal with radios and checks. And I guessed that we wasnt the only users likely to encounter this. So of course, I would like to see wicket was improved on this point, either by me or somebody else (doesnt really matter who does the work), just that its done. However if this means that we are crapping wicket up in some way, thats a bad turn to take. I think i'll ask the user list how many peeps does performance tests that needs to be stable over a longer periode. Or what peeps in general does to performance test their application. It might just be us who has an strict contract with our customer. -regards Nino Fra: [EMAIL PROTECTED] på vegne af Igor Vaynberg Sendt: sø 01-04-2007 21:15 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? On 4/1/07, Nino Wael [EMAIL PROTECTED] wrote: I do know that radio and check are directly attached to their imodel. But the imodel does not provide an alternate value for them. I just dont see why not to provide an ichoicerender on these components when providing it for the radiochoice and dropdown choice. 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. We have no way of controlling the value of the radios when using this component. yes, you are not meant to have control over it - it is an implementation detail of that component. And since we cant overide the getValue we are either stuck or need to use another component. But that implicates some redesign, and it's a little late for that now on our project at least. why do people keep bring up arguments like this? it is very annoying. is it our fault that you are in this situation? you put yourself there. now you expect us to make our component worse for all our users so that you can get out of a corner you painted yourself into? Hmm this maybe something for wicket-stuff or extensions then.. or for your own code tree. it is easy to copy/paste radio into your own code and remove whatever final is in your way. since your code is imported first on the classpath it will simply override whatever wicket has, given you do not change package name and class name. -igor regards Nino -Original Message- From: [EMAIL PROTECTED] on behalf of Igor Vaynberg Sent: Fri 30-03-2007 17:15 To: wicket-user@lists.sourceforge.net Subject: Re: [Wicket-user] Radio.getValue? radio and check do not take an ichoicerenderer because they do not need it. they do not traverse over a list of choices and try to look one up, they have the choice attached directly to them via imodel. -igor On 3/30/07, Nino Wael [EMAIL PROTECTED] wrote: That was whý I suggested that we could have another constructor that took an Ichoicerender. There are tons of places in other wicket core components that supply a constructor that takes the ichoicerender. SO I think
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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
On 4/1/07, Nino Wael [EMAIL PROTECTED] wrote: I do know that radio and check are directly attached to their imodel. But the imodel does not provide an alternate value for them. I just dont see why not to provide an ichoicerender on these components when providing it for the radiochoice and dropdown choice. 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. We have no way of controlling the value of the radios when using this component. yes, you are not meant to have control over it - it is an implementation detail of that component. And since we cant overide the getValue we are either stuck or need to use another component. But that implicates some redesign, and it's a little late for that now on our project at least. why do people keep bring up arguments like this? it is very annoying. is it our fault that you are in this situation? you put yourself there. now you expect us to make our component worse for all our users so that you can get out of a corner you painted yourself into? Hmm this maybe something for wicket-stuff or extensions then.. or for your own code tree. it is easy to copy/paste radio into your own code and remove whatever final is in your way. since your code is imported first on the classpath it will simply override whatever wicket has, given you do not change package name and class name. -igor regards Nino -Original Message- From: [EMAIL PROTECTED] on behalf of Igor Vaynberg Sent: Fri 30-03-2007 17:15 To: wicket-user@lists.sourceforge.net Subject: Re: [Wicket-user] Radio.getValue? radio and check do not take an ichoicerenderer because they do not need it. they do not traverse over a list of choices and try to look one up, they have the choice attached directly to them via imodel. -igor On 3/30/07, Nino Wael [EMAIL PROTECTED] wrote: That was whý I suggested that we could have another constructor that took an Ichoicerender. There are tons of places in other wicket core components that supply a constructor that takes the ichoicerender. SO I think it should be ok? I would really like that ichoicerenderer would be supported by every component where it makes sense... Should we move this do the dev list? regards Nino Fra: [EMAIL PROTECTED] på vegne af Igor Vaynberg Sendt: to 29-03-2007 19:11 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? On 3/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Looking at that code, I don't understand why we even need: private short uuid = -1; as there is no code other than in getValue that changes the value, and that value can just be recreated everytime it is needed (as it is nothing more than a call to getPage().getAutoIndex()). Am I missing something here? yes, you are missing the fact that getautoindex() increments the index on every call that is why we cache it in the uuid var. WDYT? personally i dont like making getvalue non-final. this will patch this component for this kind of testing, but what about other components that do not have a stable name? are we going to have to start opening implementation details on all of them just because users want to test it with something static like httpunit? just my 2c. -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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - 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.phpp=sourceforgeCID=DEVDEV___
Re: [Wicket-user] Radio.getValue?
I do know that radio and check are directly attached to their imodel. But the imodel does not provide an alternate value for them. I just dont see why not to provide an ichoicerender on these components when providing it for the radiochoice and dropdown choice. We have no way of controlling the value of the radios when using this component. And since we cant overide the getValue we are either stuck or need to use another component. But that implicates some redesign, and it's a little late for that now on our project at least. Hmm this maybe something for wicket-stuff or extensions then.. regards Nino -Original Message- From: [EMAIL PROTECTED] on behalf of Igor Vaynberg Sent: Fri 30-03-2007 17:15 To: wicket-user@lists.sourceforge.net Subject: Re: [Wicket-user] Radio.getValue? radio and check do not take an ichoicerenderer because they do not need it. they do not traverse over a list of choices and try to look one up, they have the choice attached directly to them via imodel. -igor On 3/30/07, Nino Wael [EMAIL PROTECTED] wrote: That was whý I suggested that we could have another constructor that took an Ichoicerender. There are tons of places in other wicket core components that supply a constructor that takes the ichoicerender. SO I think it should be ok? I would really like that ichoicerenderer would be supported by every component where it makes sense... Should we move this do the dev list? regards Nino Fra: [EMAIL PROTECTED] på vegne af Igor Vaynberg Sendt: to 29-03-2007 19:11 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? On 3/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Looking at that code, I don't understand why we even need: private short uuid = -1; as there is no code other than in getValue that changes the value, and that value can just be recreated everytime it is needed (as it is nothing more than a call to getPage().getAutoIndex()). Am I missing something here? yes, you are missing the fact that getautoindex() increments the index on every call that is why we cache it in the uuid var. WDYT? personally i dont like making getvalue non-final. this will patch this component for this kind of testing, but what about other components that do not have a stable name? are we going to have to start opening implementation details on all of them just because users want to test it with something static like httpunit? just my 2c. -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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user winmail.dat- 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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
That was whý I suggested that we could have another constructor that took an Ichoicerender. There are tons of places in other wicket core components that supply a constructor that takes the ichoicerender. SO I think it should be ok? I would really like that ichoicerenderer would be supported by every component where it makes sense... Should we move this do the dev list? regards Nino Fra: [EMAIL PROTECTED] på vegne af Igor Vaynberg Sendt: to 29-03-2007 19:11 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? On 3/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Looking at that code, I don't understand why we even need: private short uuid = -1; as there is no code other than in getValue that changes the value, and that value can just be recreated everytime it is needed (as it is nothing more than a call to getPage().getAutoIndex()). Am I missing something here? yes, you are missing the fact that getautoindex() increments the index on every call that is why we cache it in the uuid var. WDYT? personally i dont like making getvalue non-final. this will patch this component for this kind of testing, but what about other components that do not have a stable name? are we going to have to start opening implementation details on all of them just because users want to test it with something static like httpunit? just my 2c. -igor winmail.dat- 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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
radio and check do not take an ichoicerenderer because they do not need it. they do not traverse over a list of choices and try to look one up, they have the choice attached directly to them via imodel. -igor On 3/30/07, Nino Wael [EMAIL PROTECTED] wrote: That was whý I suggested that we could have another constructor that took an Ichoicerender. There are tons of places in other wicket core components that supply a constructor that takes the ichoicerender. SO I think it should be ok? I would really like that ichoicerenderer would be supported by every component where it makes sense... Should we move this do the dev list? regards Nino Fra: [EMAIL PROTECTED] på vegne af Igor Vaynberg Sendt: to 29-03-2007 19:11 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? On 3/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Looking at that code, I don't understand why we even need: private short uuid = -1; as there is no code other than in getValue that changes the value, and that value can just be recreated everytime it is needed (as it is nothing more than a call to getPage().getAutoIndex()). Am I missing something here? yes, you are missing the fact that getautoindex() increments the index on every call that is why we cache it in the uuid var. WDYT? personally i dont like making getvalue non-final. this will patch this component for this kind of testing, but what about other components that do not have a stable name? are we going to have to start opening implementation details on all of them just because users want to test it with something static like httpunit? just my 2c. -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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - 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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
I don't know... you might be better off just creating your own components here. But I'd also like to know the opinions of other developers here... Eelco On 3/30/07, Nino Wael [EMAIL PROTECTED] wrote: That was whý I suggested that we could have another constructor that took an Ichoicerender. There are tons of places in other wicket core components that supply a constructor that takes the ichoicerender. SO I think it should be ok? I would really like that ichoicerenderer would be supported by every component where it makes sense... Should we move this do the dev list? regards Nino Fra: [EMAIL PROTECTED] på vegne af Igor Vaynberg Sendt: to 29-03-2007 19:11 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? On 3/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Looking at that code, I don't understand why we even need: private short uuid = -1; as there is no code other than in getValue that changes the value, and that value can just be recreated everytime it is needed (as it is nothing more than a call to getPage().getAutoIndex()). Am I missing something here? yes, you are missing the fact that getautoindex() increments the index on every call that is why we cache it in the uuid var. WDYT? personally i dont like making getvalue non-final. this will patch this component for this kind of testing, but what about other components that do not have a stable name? are we going to have to start opening implementation details on all of them just because users want to test it with something static like httpunit? just my 2c. -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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
pinging/bump Eelco to answer:) Fra: [EMAIL PROTECTED] på vegne af Nino Wael Sendt: on 28-03-2007 09:54 Til: wicket-user@lists.sourceforge.net Emne: SV: [Wicket-user] Radio.getValue? Ok, let me try to explain another way. If you create a page where you use the radio component. The radios represent various kinds of datasets(OLAP cubes in this case but it does not really matter). On monday the 1. march you record with jmeter your test case(jmeter only records the http requests). In your test case you must select the retirement dataset (which has the value radio5 on the html page). Some time has passed now and you want to run your jmeter test, but on your page some of the datasets has been removed (they wasnt needed or was not allowed to be shown). So now the page no longer contains the radio with the value radio5, and your jmeter test will fail because wicket cant find the radio(another error scenario would be if the radios changed order). So if radio component allowed the use of Ichoicerenderer, it could generate the value based on the id of the ichoicerenderer for the particular dataitem. This would bring better persistance to the radios. At least when testing with jmeter. Did I do a better job explaining?:) Some could argue that it's not issue, but it would be very handy to have the ability to use the ichoicerender with every component that makes use of the value attribute in inputs(havent thought it through though). Because it would make it easier to use tools as jmeter. I would suggest that to avoid nameclashing we could use the components name.getIdValue as value attribute. I am aware that this would bring in a possible vuernability, if duplicate items are inserted and that could cause problems i guess? regards Nino Fra: [EMAIL PROTECTED] på vegne af Eelco Hillenius Sendt: ti 27-03-2007 18:40 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? I'm afraid I don't really understand your problem Nino. Eelco On 3/26/07, Nino Wael [EMAIL PROTECTED] wrote: Hi We are doing some extensive Jmeter testing, and have run into a technical problem regarding radios, which are the following: If you had 5 radios on a page at a given time, their value would have been radio1, radio2.. radio5. If you then pulled out radio number 4 then the list would be this, radio1, radio2 .. radio4. Now only the one previously called radio4 should not have been selectable. This renders our jmeter test pretty vuernable if some of the stuff no longer are available. Im not sure if I can use a ichoicerenderer, looking at the code from getValue, it's pretty hardcoded am I correct? If possible i'd like to just use the IChoiceRenderer's getId instead, that should fix the problem. regards Nino - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user winmail.dat- 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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
Ok, let me try to explain another way. If you create a page where you use the radio component. The radios represent various kinds of datasets(OLAP cubes in this case but it does not really matter). On monday the 1. march you record with jmeter your test case(jmeter only records the http requests). In your test case you must select the retirement dataset (which has the value radio5 on the html page). Some time has passed now and you want to run your jmeter test, but on your page some of the datasets has been removed (they wasnt needed or was not allowed to be shown). So now the page no longer contains the radio with the value radio5, and your jmeter test will fail because wicket cant find the radio(another error scenario would be if the radios changed order). So if radio component allowed the use of Ichoicerenderer, it could generate the value based on the id of the ichoicerenderer for the particular dataitem. This would bring better persistance to the radios. At least when testing with jmeter. Did I do a better job explaining?:) I think I got ya :) Some could argue that it's not issue, but it would be very handy to have the ability to use the ichoicerender with every component that makes use of the value attribute in inputs(havent thought it through though). Because it would make it easier to use tools as jmeter. It would also use a bit more memory and make it's API bigger and thus more complex I'm afraid. I'm not sure whether it is a good feature to build in by default. An alternative could be to enable users to provide their own implementation, i.e. by making getValue non-final. Looking at that code, I don't understand why we even need: private short uuid = -1; as there is no code other than in getValue that changes the value, and that value can just be recreated everytime it is needed (as it is nothing more than a call to getPage().getAutoIndex()). Am I missing something here? WDYT? Eelco - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
On 3/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Looking at that code, I don't understand why we even need: private short uuid = -1; as there is no code other than in getValue that changes the value, and that value can just be recreated everytime it is needed (as it is nothing more than a call to getPage().getAutoIndex()). Am I missing something here? yes, you are missing the fact that getautoindex() increments the index on every call that is why we cache it in the uuid var. WDYT? personally i dont like making getvalue non-final. this will patch this component for this kind of testing, but what about other components that do not have a stable name? are we going to have to start opening implementation details on all of them just because users want to test it with something static like httpunit? just my 2c. -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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
On 3/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Looking at that code, I don't understand why we even need: private short uuid = -1; as there is no code other than in getValue that changes the value, and that value can just be recreated everytime it is needed (as it is nothing more than a call to getPage().getAutoIndex()). Am I missing something here? yes, you are missing the fact that getautoindex() increments the index on every call that is why we cache it in the uuid var. Of course. Eelco - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
Ok, let me try to explain another way. If you create a page where you use the radio component. The radios represent various kinds of datasets(OLAP cubes in this case but it does not really matter). On monday the 1. march you record with jmeter your test case(jmeter only records the http requests). In your test case you must select the retirement dataset (which has the value radio5 on the html page). Some time has passed now and you want to run your jmeter test, but on your page some of the datasets has been removed (they wasnt needed or was not allowed to be shown). So now the page no longer contains the radio with the value radio5, and your jmeter test will fail because wicket cant find the radio(another error scenario would be if the radios changed order). So if radio component allowed the use of Ichoicerenderer, it could generate the value based on the id of the ichoicerenderer for the particular dataitem. This would bring better persistance to the radios. At least when testing with jmeter. Did I do a better job explaining?:) Some could argue that it's not issue, but it would be very handy to have the ability to use the ichoicerender with every component that makes use of the value attribute in inputs(havent thought it through though). Because it would make it easier to use tools as jmeter. I would suggest that to avoid nameclashing we could use the components name.getIdValue as value attribute. I am aware that this would bring in a possible vuernability, if duplicate items are inserted and that could cause problems i guess? regards Nino Fra: [EMAIL PROTECTED] på vegne af Eelco Hillenius Sendt: ti 27-03-2007 18:40 Til: wicket-user@lists.sourceforge.net Emne: Re: [Wicket-user] Radio.getValue? I'm afraid I don't really understand your problem Nino. Eelco On 3/26/07, Nino Wael [EMAIL PROTECTED] wrote: Hi We are doing some extensive Jmeter testing, and have run into a technical problem regarding radios, which are the following: If you had 5 radios on a page at a given time, their value would have been radio1, radio2.. radio5. If you then pulled out radio number 4 then the list would be this, radio1, radio2 .. radio4. Now only the one previously called radio4 should not have been selectable. This renders our jmeter test pretty vuernable if some of the stuff no longer are available. Im not sure if I can use a ichoicerenderer, looking at the code from getValue, it's pretty hardcoded am I correct? If possible i'd like to just use the IChoiceRenderer's getId instead, that should fix the problem. regards Nino - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user winmail.dat- 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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
Hmm I can see that radio are pretty simple on this, no constructors with ichoicerenderer. I guess the only way it can work are if some one creates a patch. I'll findout how bad we want this not to be a problem, if we want it bad. I'll create a fix for it. If I create a fix, could it be patched back into wicket 1.2.4? regards Nino -Oprindelig meddelelse- Fra: [EMAIL PROTECTED] på vegne af Nino Wael Sendt: ti 27-03-2007 08:22 Til: wicket-user@lists.sourceforge.net Emne: Radio.getValue? Hi We are doing some extensive Jmeter testing, and have run into a technical problem regarding radios, which are the following: If you had 5 radios on a page at a given time, their value would have been radio1, radio2.. radio5. If you then pulled out radio number 4 then the list would be this, radio1, radio2 .. radio4. Now only the one previously called radio4 should not have been selectable. This renders our jmeter test pretty vuernable if some of the stuff no longer are available. Im not sure if I can use a ichoicerenderer, looking at the code from getValue, it's pretty hardcoded am I correct? If possible i'd like to just use the IChoiceRenderer's getId instead, that should fix the problem. regards Nino winmail.dat- 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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
hmm, the same thing applies to checkbox component. -Oprindelig meddelelse- Fra: [EMAIL PROTECTED] på vegne af Nino Wael Sendt: ti 27-03-2007 12:15 Til: wicket-user@lists.sourceforge.net Emne: SV: Radio.getValue? Hmm I can see that radio are pretty simple on this, no constructors with ichoicerenderer. I guess the only way it can work are if some one creates a patch. I'll findout how bad we want this not to be a problem, if we want it bad. I'll create a fix for it. If I create a fix, could it be patched back into wicket 1.2.4? regards Nino -Oprindelig meddelelse- Fra: [EMAIL PROTECTED] på vegne af Nino Wael Sendt: ti 27-03-2007 08:22 Til: wicket-user@lists.sourceforge.net Emne: Radio.getValue? Hi We are doing some extensive Jmeter testing, and have run into a technical problem regarding radios, which are the following: If you had 5 radios on a page at a given time, their value would have been radio1, radio2.. radio5. If you then pulled out radio number 4 then the list would be this, radio1, radio2 .. radio4. Now only the one previously called radio4 should not have been selectable. This renders our jmeter test pretty vuernable if some of the stuff no longer are available. Im not sure if I can use a ichoicerenderer, looking at the code from getValue, it's pretty hardcoded am I correct? If possible i'd like to just use the IChoiceRenderer's getId instead, that should fix the problem. regards Nino winmail.dat- 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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Radio.getValue?
I'm afraid I don't really understand your problem Nino. Eelco On 3/26/07, Nino Wael [EMAIL PROTECTED] wrote: Hi We are doing some extensive Jmeter testing, and have run into a technical problem regarding radios, which are the following: If you had 5 radios on a page at a given time, their value would have been radio1, radio2.. radio5. If you then pulled out radio number 4 then the list would be this, radio1, radio2 .. radio4. Now only the one previously called radio4 should not have been selectable. This renders our jmeter test pretty vuernable if some of the stuff no longer are available. Im not sure if I can use a ichoicerenderer, looking at the code from getValue, it's pretty hardcoded am I correct? If possible i'd like to just use the IChoiceRenderer's getId instead, that should fix the problem. regards Nino - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] Radio.getValue?
Hi We are doing some extensive Jmeter testing, and have run into a technical problem regarding radios, which are the following: If you had 5 radios on a page at a given time, their value would have been radio1, radio2.. radio5. If you then pulled out radio number 4 then the list would be this, radio1, radio2 .. radio4. Now only the one previously called radio4 should not have been selectable. This renders our jmeter test pretty vuernable if some of the stuff no longer are available. Im not sure if I can use a ichoicerenderer, looking at the code from getValue, it's pretty hardcoded am I correct? If possible i'd like to just use the IChoiceRenderer's getId instead, that should fix the problem. regards Nino winmail.dat- 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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
