the stackbased approach could just be an implementation of the ISupplyConverters yes.But using a stack or a map doesn't make a difference from the outside world (looking at getConverter(Class))Or are you saying that constantly that stack is altered? And converters are pushed and popped?
What usecas
So now he have two possible alternatives.
One is Igor's stack based, other one yours using ISuplyConverters.
Both seem fine to me. The ISupplyConverters alternative is more
flexible, question is though, whether more flexibility is what we need
here.
So maybe there should be vote about it? Or
yeah the compound was just nothing more then getting a type converter..It was more or less a hack in the interface (in my eyes) to get around the problem for getting the right one.And if you want "compound" that is still possible because that is ISupplyConveter
johanOn 5/18/06, Matej Knopp <[EMAIL
I kind of like this one. Except that it doesn't allow
CompoundConverters. But then again, with concept like this there is no
need for compound converters.
-Matej
Igor Vaynberg wrote:
yes i know it was never a stack, i propose to make it a stack
i was talking about the usecase of replacing th
yes i know it was never a stack, i propose to make it a stacki was talking about the usecase of replacing the default converterfactory to globally install your own converter.youd have to do something like this:
newConver(Class c) { if (c==myclass) { return new MyConverter(); else return de
everybody used it to replace stuff.Because everybody now needed to (or did) override the component getConveter()and it was never a stack by the way, it was always a map (but in the end the result is the same ofcourse)
But that doesn't matter and that is still possible because we have still the fact
supports wasnt to replace the type parameters, it was to ease with registrationinstead of doing something likeMap registry;registry.put(String.class, new StringConverter());registry.get
(String.class);you haveStack registry;stack.push(new StringConverter());and you search for the converter by itera
i like that idea ;)I will commit it when the trunk is 2.0 and then you guys can fight about it and see how it worksI think the current impl i have right now is much much easier to use.johan
On 5/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Maybe we just let Johan implement it, and then see wha
i have refactored it a bit morenow i have this an interface like this (naming can be changed of course)public interface ISupplyConverters extends Serializable{ public IConverter getConverter(Class type);
}This is already implemented by 3 classes:Component, Session and ConverterSupplier (which wa
Maybe we just let Johan implement it, and then see what he has when it's done :)
Eelco
On 5/17/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Eelco Hillenius wrote:
> I'm still a bit worried about the naming etc.
>
> In my opinion, the thing we want to do is to do input-output
> conversion for mod
Eelco Hillenius wrote:
I'm still a bit worried about the naming etc.
In my opinion, the thing we want to do is to do input-output
conversion for models. Models could do this themselves, but pulling
the conversion out makes things way more flexible. So... as this is
what we are doing, I would pro
I'm still a bit worried about the naming etc.
In my opinion, the thing we want to do is to do input-output
conversion for models. Models could do this themselves, but pulling
the conversion out makes things way more flexible. So... as this is
what we are doing, I would propose to choose a name th
we might also consider adding IConverter.supports(Class) to make registration easier.-IgorOn 5/14/06, Johan Compagner <
[EMAIL PROTECTED]> wrote:Hi,first currently we have IConverter and ITypeConverter , i want to combine those 2 to be one interface
And then a converter must be easy to make but als
I am quite happy with you current proposition. It seem to be flexible
enough to allow compound converters, while also being simple enough to
make your own converter. And there is only one interface, which is IMHO
a lot better and a lot less confusing than current IConverter and
ITypeConverter s
that is not a problem. just add youre String.class converter to the "compound" session Converter Or override getConverter() and return yours.you now know what is outgoing and incomming with that interface so that shouldn't be a problem
But when the trunk is ready for 2.0 code. Lets test it out and
Johan,It would be nice to have an ability to convert from string to string for fields like phone numbers, zip codes, ssn, etc.AlexOn 5/14/06,
Johan Compagner <[EMAIL PROTECTED]> wrote:
Hi,first currently we have IConverter and ITypeConverter , i want to combine those 2 to be one interfaceAnd then
Johan Compagner wrote:
Hi,
first currently we have IConverter and ITypeConverter , i want to
combine those 2 to be one interface
And then a converter must be easy to make but also to understand.
So i can do this:
IConverter.convertToObject (String, Class)
IConverter.convertToString(Object)
Hi,first currently we have IConverter and ITypeConverter , i want to combine those 2 to be one interfaceAnd then a converter must be easy to make but also to understand.So i can do this:IConverter.convertToObject
(String, Class)IConverter.convertToString(Object)Then writing a DateConverter is prett
18 matches
Mail list logo
