|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 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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
