deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <arne.limb...@openknowledge.de>
Subject AW: About Converter framework vote
Date Thu, 14 Jun 2012 08:09:52 GMT
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 <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 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
>> 


Mime
View raw message