You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Antoine Sabot-Durand <an...@sabot-durand.net> on 2012/06/14 08:02:44 UTC
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 obvious that a converter framework would be very useful here since we won't have JSF to deal with it. We'll have to create some batch POC, again converter would 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 ambitious by bringing missing features for the whole Java EE 6 stack. You probably guessed that I prefer the second solution ;-).
Antoine Sabot-Durand
-------------------------------
http://agorava.org
@antoine_sd
AW: About Converter framework vote
Posted by Arne Limburg <ar...@openknowledge.de>.
We can think about very basic conversion support, i.e.
Conversion from Object to String: Use toString()
Conversion from String to Object: Use the Constructor that has only one argument of type String, if available (we would get Support for Integer, Long, Double, Float, even java.io.File, java.net.URL, java.net.URI)
Cheers,
Arne
-----Ursprüngliche Nachricht-----
Von: Pete Muir [mailto:pmuir@redhat.com]
Gesendet: Donnerstag, 14. Juni 2012 09:51
An: deltaspike-dev@incubator.apache.org; Mark Struberg
Betreff: Re: About Converter framework vote
Agree with Mark, much better to CDI enable a converter framework in DS, than 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 such a thing, I'd keep all the Converter logic purely native Java and additionally 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 way to go imo.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Antoine Sabot-Durand <an...@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 obvious that a converter framework would be very useful
>> here since we won't have JSF to deal with it. We'll have to create
>> some batch POC, again converter would 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 ambitious by bringing missing features for the whole Java
>> EE 6 stack. You probably guessed that I prefer the second solution ;-).
>>
>> Antoine Sabot-Durand
>> -------------------------------
>> http://agorava.org
>> @antoine_sd
>>
Re: About Converter framework vote
Posted by Antoine Sabot-Durand <an...@sabot-durand.net>.
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 à 09:51, Pete Muir <pm...@redhat.com> a écrit :
> Agree with Mark, much better to CDI enable a converter framework in DS, than 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 such a thing, I'd keep all the Converter logic purely native Java and additionally 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 way to go imo.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Antoine Sabot-Durand <an...@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 obvious
>>> that a converter framework would be very useful here since we won't have JSF
>>> to deal with it. We'll have to create some batch POC, again converter would
>>> 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 ambitious by
>>> bringing missing features for the whole Java EE 6 stack. You probably guessed
>>> that I prefer the second solution ;-).
>>>
>>> Antoine Sabot-Durand
>>> -------------------------------
>>> http://agorava.org
>>> @antoine_sd
>>>
>
Re: About Converter framework vote
Posted by Pete Muir <pm...@redhat.com>.
Agree with Mark, much better to CDI enable a converter framework in DS, than 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 such a thing, I'd keep all the Converter logic purely native Java and additionally 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 way to go imo.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Antoine Sabot-Durand <an...@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 obvious
>> that a converter framework would be very useful here since we won't have JSF
>> to deal with it. We'll have to create some batch POC, again converter would
>> 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 ambitious by
>> bringing missing features for the whole Java EE 6 stack. You probably guessed
>> that I prefer the second solution ;-).
>>
>> Antoine Sabot-Durand
>> -------------------------------
>> http://agorava.org
>> @antoine_sd
>>
Re: About Converter framework vote
Posted by Mark Struberg <st...@yahoo.de>.
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 such a thing, I'd keep all the Converter logic purely native Java and additionally 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 way to go imo.
LieGrue,
strub
----- Original Message -----
> From: Antoine Sabot-Durand <an...@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 obvious
> that a converter framework would be very useful here since we won't have JSF
> to deal with it. We'll have to create some batch POC, again converter would
> 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 ambitious by
> bringing missing features for the whole Java EE 6 stack. You probably guessed
> that I prefer the second solution ;-).
>
> Antoine Sabot-Durand
> -------------------------------
> http://agorava.org
> @antoine_sd
>