deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [VOTE] Converter framework
Date Thu, 14 Jun 2012 06:15:16 GMT


Yes, perfectly fine to explore the Converter stuff in a feature branch and also perfectly
fine to even do this in master IF we found a GOOD use case for it!

I'm not a priori against adding new features, even if they are a bit more heavyweight. But
I really see no reason for adding complex stuff which has no use case so far.

This also doesn't mean that this work was done badly and unimportant. It just means that -
after a thorough review - we found an even better solution. Nontheless, Gerhards input was
really important, as it provided a base ground for an in depth discussion and review. Sometimes
we need to test different ideas and ways and only when implementing it you will see if it
gets complicated or if it turns out nicely.

LieGrue,
strub


PS: I'd be more than happy if our EE experts review the ConfigurableDataSource in depth _and_
if we get some input about a possible JTA module (see the discussion with Jason a few days
back).



>________________________________
> From: Antoine Sabot-Durand <antoine@sabot-durand.net>
>To: deltaspike-dev@incubator.apache.org; Mark Struberg <struberg@yahoo.de> 
>Sent: Thursday, June 14, 2012 8:03 AM
>Subject: Re: [VOTE] Converter framework
> 
>
>+1 now but keep it for later.
>
>
>Antoine SABOT-DURAND
>---------------------------------------
>http://agorava.og
>@antoine_sd
>
>
>
>Le 14 juin 2012 à 06:44, Mark Struberg a écrit :
>
>a.) What is this for? -> no one knows
>>b.) Do we need it in DeltaSpike? -> not yet.
>>c.) Do we need it for JSF? -> No, JSF has it's own Converter logic
>>d.) Do we need it somewhere else? -> No, not afaik
>>
>>So let's drop the Converter stuff which is currently of no use and really complicated
to get right?
>>Just remember that this was more or less a 1:1 copy of the Spring logic which has
not so easily extendible producer methods.
>>
>>[+1] Drop it, our code will get complicated enough anyway
>>
>>[+0] Meh, don't care
>>
>>[-1]  keep it because it is very important (+ give use case and reasons)
>>
>>LieGrue,
>>strub
>>
>
>
>

Mime
View raw message