Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
References: <1339649080.8905.YahooMailNeo@web171504.mail.ir2.yahoo.com>
 <10F8B5E1-EDCF-4CE8-9DDC-463F4D6A2E08@sabot-durand.net>
 <1339654896.4894.YahooMailNeo@web171504.mail.ir2.yahoo.com>
 <DCBD28BE-D496-4ABC-A757-DE4E277C582B@redhat.com>
From: Antoine Sabot-Durand <antoine@sabot-durand.net>
In-Reply-To: <DCBD28BE-D496-4ABC-A757-DE4E277C582B@redhat.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 14 Jun 2012 10:20:29 +0200
Message-ID: <3085002747243430006@unknownmsgid>
Subject: Re: About Converter framework vote
To: "deltaspike-dev@incubator.apache.org"
 <deltaspike-dev@incubator.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I was obviously not clear enough. I didn't say DS should redevelop
what already exist but should perhaps integrate it.
When I read that there are no use cases for converter since JSF
provides it, it makes me react.

Antoine

Le 14 juin 2012 =E0 09:51, Pete Muir <pmuir@redhat.com> a =E9crit :

> Agree with Mark, much better to CDI enable a converter framework in DS, t=
han make a whole converter framework :-)
>
> On 14 Jun 2012, at 07:21, Mark Struberg wrote:
>
>> Hi Antoine!
>>
>> DS is imo clearly not only targeting JSF!
>>
>> And I wasn't saying that a Converter framework wont be fine.
>>
>> BUT: writing this _properly_ is a pretty complex task, and it has barely=
 to do with DeltaSpike as it is not CDI depending. In fact, if I would do s=
uch a thing, I'd keep all the Converter logic purely native Java and additi=
onally provide bindings to CDI and Spring.
>>
>>
>> I think there is already some Converter work done in Apache commons btw.=
 - a converter framework in commons which can be used universally is the wa=
y to go imo.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Antoine Sabot-Durand <antoine@sabot-durand.net>
>>> To: deltaspike-dev@incubator.apache.org
>>> Cc:
>>> Sent: Thursday, June 14, 2012 8:02 AM
>>> Subject: About Converter framework vote
>>>
>>> Hi,
>>>
>>> I'll probably vote +1 but wanted to comment this point
>>>
>>>> a.) What is this for? -> no one knows
>>>
>>> As I was away for a long time (Launching Agorava) I won't comment this
>>>
>>>> b.) Do we need it in DeltaSpike? -> not yet.
>>>
>>> Yes you're probably right : we have more important things to deal with =
now
>>>
>>>> c.) Do we need it for JSF? -> No, JSF has it's own Converter logic
>>>
>>> Yes, but JSF is not the only use case for using  CDI
>>>
>>>> d.) Do we need it somewhere else? -> No, not afaik
>>>
>>> That's the point I don't agree with. I'm working on Java EE 6 POCS
>>> for a customer. One go this POC is a full rest application using HTML5 =
techs on
>>> client and Jax-RS / CDI  and other Java EE tech on the server. It's obv=
ious
>>> that a converter framework would be very useful here since we won't hav=
e JSF
>>> to deal with it. We'll have to create some batch POC, again converter w=
ould
>>> be nice.
>>>
>>> In fact it questions the goals of DS. We all agree on the fact that DS =
should
>>> provide a way to ease CDI extension development. But beyond that should=
 it
>>> provide only tools ease to JSF development or should it be more ambitio=
us by
>>> bringing missing features for the whole Java EE 6 stack. You probably g=
uessed
>>> that I prefer the second solution ;-).
>>>
>>> Antoine Sabot-Durand
>>> -------------------------------
>>> http://agorava.org
>>> @antoine_sd
>>>
>