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 <[email protected]> >To: [email protected]; Mark Struberg <[email protected]> >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 >> > > >
