it must handle string[] because sometimes for a multiselect it returns
a collection. I guess that is tricky thing to put into the converter
interface :(
On 7/11/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 7/11/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>
> On 7/11/07, Gwyn Evans <[EMAIL
On 7/11/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
On 7/11/07, Gwyn Evans <[EMAIL PROTECTED]> wrote:
> I did want to respond to Johan's comment, but it's /not/ a -1 vote,
> especially in view of your reasons above - "0" if anything.
I didn't want to imply as such, but I would not hold a gr
On 7/11/07, Gwyn Evans <[EMAIL PROTECTED]> wrote:
I did want to respond to Johan's comment, but it's /not/ a -1 vote,
especially in view of your reasons above - "0" if anything.
I didn't want to imply as such, but I would not hold a grudge if you
would -1 it. It is late in the game, so ...
Mar
On Wednesday, July 11, 2007, 10:53:18 AM, Martijn <[EMAIL PROTECTED]> wrote:
> On 7/11/07, Gwyn Evans <[EMAIL PROTECTED]> wrote:
>> I do - that's the reason that we /always/ slip releases, as there's
>> /always/ just one more "let's tidy this up" change.
>> It also means that committers don't fee
On 7/11/07, Gwyn Evans <[EMAIL PROTECTED]> wrote:
I do - that's the reason that we /always/ slip releases, as there's
/always/ just one more "let's tidy this up" change.
It also means that committers don't feel any big urge to ship
releases, as they're still tweaking as they want, while normal
On Wednesday, July 11, 2007, 9:19:51 AM, Johan <[EMAIL PROTECTED]> wrote:
>>
>> Ugh. We still seem to be changing lots of fundamental stuff, don't we. :-)
>>
>> I vote:
>> [x] deprecate them for beta3
>>
>> We could possibly remove them for rc1, but that makes migration from
>> 1.2.x harder, doesn
so you always want to call getConverter()
and if typename is not set you get a null param?
and then all the components that now implemements convertValue(String[]
values)
should override getConverted(Class) and test for null and if it is null
then return a converter which does the same as convert
Al Maw wrote:
In my opinion, if you override getConverter() then it should always be
used, even if that means we have to call it with a null type parameter.
(Normally when you're overriding it for a particular component you don't
care about the type parameter anyway).
Looking at this further,
Johan Compagner wrote:
this constructor can be deleted yes:
public TextField(final String id, final Class type)
{
super(id);
setType(type);
}
but i don't know about this one:
public TextField(final String id, IModel model, Class type)
{
super(id, model);
Ugh. We still seem to be changing lots of fundamental stuff, don't we. :-)
I vote:
[x] deprecate them for beta3
We could possibly remove them for rc1, but that makes migration from
1.2.x harder, doesn't it?
i personally don't care that much about breaking stuff for 1.3.
We really need to st
this constructor can be deleted yes:
public TextField(final String id, final Class type)
{
super(id);
setType(type);
}
but i don't know about this one:
public TextField(final String id, IModel model, Class type)
{
super(id, model);
setType(type);
}
b
Martijn Dashorst wrote:
Matej had the brilliant idea of auto discovery of the type parameter
for FormComponents when they use a PropertyModel or
CompoundPropertyModel. In order to remove confusion for noobs, and to
point out that there is a Better Way (tm) I propose the following
options:
For th
Considering that having more than one constructor seems to scare out
noobs (take a look at DDC for a prime example), having them, when they
are not necessary, is not good for the API.
The constructor of a component is the first thing any one sees when
using it (apart from the LongAndVerboseClassN
either
[ x ] remove the affected FormComponent constructors with the type parameter
or
[ x ] deprecate the affected FormComponent constructors with the type parameter
Eelco
Sorry for not voting in this reply, but do you really consider the
constructor with type parameter confusing for noobs?
-Matej
On 7/10/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Matej had the brilliant idea of auto discovery of the type parameter
for FormComponents when they use a Property
[x] deprecate the affected FormComponent constructors with the type
parameter
-igor
Matej had the brilliant idea of auto discovery of the type parameter
for FormComponents when they use a PropertyModel or
CompoundPropertyModel. In order to remove confusion for noobs, and to
point out that there is a Better Way (tm) I propose the following
options:
For those wondering if it is st
17 matches
Mail list logo
