You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Oliver Heger <he...@med.uni-marburg.de> on 2004/03/16 08:29:22 UTC
[convert]conversion with default values
I created a patch in bugzilla (bug ID 27639) that implements a
conversion that supports default values if either null values are to be
converted or a conversion causes an exception. This conversion and its
corresonding conversion factory are implemented as decorators so they
can be attached to arbitrary other conversions.
To get a better understanding for the convert2 codebase I tried to write
a simple Object to Integer conversion. I ended up with a base class for
conversions from Object to arbitrary types, which should simplify
construction of concrete conversions and their factories. I think now I
understand what you meant by "support of inheritence without bothering
the registry". These base classes and the Object to Integer conversion
classes are also in the patch file. I hope this is useful.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [convert] conversion with default values
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Basically the sooner you can make available ideas/designs/code the more it
can be talked about ;-)
Stephen
----- Original Message -----
From: "Ron Blaschke" <ma...@rblasch.org>
> SC> Anyway, what you can do is to join the mailing list, if you haven't
already
> SC> (commons-dev@jakarta.apache.org, emails prefixed by [convert]) . Then
submit
> SC> your code as a patch to Bugzilla if you can (is it yours to donate to
> SC> Apache?).
>
> I am already subscribed to commons-dev. The prototype is based on the
> old convert code, which I used as a starting point.
> The code, apart from the old convert stuff and a heavily modified
> shortest path lookup implementation (guess I'd still better ask the
> author for permission before submitting it), is mine.
>
> SC> Everyone should also take a good look at the new website and the new
code,
> SC> which I'm hoping will be the basis for things going forward.
>
> Would it be better if, instead of submitting my old proto, I'd provide
> a xdocs where I put together all of the stuff I had in mind?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [convert] conversion with default values
Posted by Ron Blaschke <ma...@rblasch.org>.
Hello Stephen,
Saturday, March 20, 2004, 9:54:53 PM, you wrote:
SC> One thing I found when I started at Commons is that things often take longer
SC> than planned ;-)
Just as anything that's related to software. ;-)
SC> Anyway, what you can do is to join the mailing list, if you haven't already
SC> (commons-dev@jakarta.apache.org, emails prefixed by [convert]) . Then submit
SC> your code as a patch to Bugzilla if you can (is it yours to donate to
SC> Apache?).
I am already subscribed to commons-dev. The prototype is based on the
old convert code, which I used as a starting point.
The code, apart from the old convert stuff and a heavily modified
shortest path lookup implementation (guess I'd still better ask the
author for permission before submitting it), is mine.
SC> Everyone should also take a good look at the new website and the new code,
SC> which I'm hoping will be the basis for things going forward.
Would it be better if, instead of submitting my old proto, I'd provide
a xdocs where I put together all of the stuff I had in mind?
Ron
--
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [convert] conversion with default values
Posted by Stephen Colebourne <sc...@btopenworld.com>.
One thing I found when I started at Commons is that things often take longer
than planned ;-) Your input is most welcome, especially as at present I have
no real ideas for how to achieve the more advanced lookups. Unfortunately I
can't offer committer rights, as Apache is very fussy about this (although
frankly over time, I've begun to doubt how wise this is).
Anyway, what you can do is to join the mailing list, if you haven't already
(commons-dev@jakarta.apache.org, emails prefixed by [convert]) . Then submit
your code as a patch to Bugzilla if you can (is it yours to donate to
Apache?).
Everyone should also take a good look at the new website and the new code,
which I'm hoping will be the basis for things going forward.
Stephen
----- Original Message -----
From: "Ron Blaschke" <ma...@rblasch.org>
> Saturday, March 20, 2004, 2:13:21 AM, you wrote:
> >> >to Integer. The trick is then to design a combination engine to allow
> >> >StringBuffer to Integer by combining StringBuffer to String plus
String
> >> >to Integer.
>
> >> Sounds interesting. Do you have already concrete ideas how such a
> >> combination engine would look like? I have thought about converters
> >> working together in a kind of chain, too, e.g. for String to Integer
> ...
> >> These are all slightly different use cases that should be supported by
> >> such an engine. What do you think?
>
> SC> Ron Blasch had some ideas on how this might work. I've cced to see if
he
> SC> wants to comment.
>
> Thanks Stephen. I'd really like to move convert forward, but received
> very litte feedback to my last posts, so I thought nobody cared too
> much.
> I have:
> - some ideas how the convert lib should look, which I think would also
> solve the problems mentioned in this thread
> - a working prototype of most of my ideas
> - lots of enthusiasm to move convert forward
>
> Stephen, how should we proceed? Would it be worth, and possible, for me
> to get commit access? Or should I keep sending things to you and/or the
> list?
>
> Ron
> --
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [common-build]
Posted by Tim O'Brien <to...@discursive.com>.
> -----Original Message-----
> From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
> Sent: Sunday, March 21, 2004 4:11 PM
> To: Jakarta Commons Developers List
> Subject: Re: [common-build]
>
> On 21 Mar 2004, at 22:12, Stephen Colebourne wrote:
>
> >> yep, I think we are settled on the design in this area. So what are
> >> your
> >> sentimate on the overall toplevel site generation. Do you feel its
> >> adequate to replace the existing contents at this time?
> >
> > I would say the time is right to update the main site. Then people can
> > comment on it and it'll get fixed from there. A kind of lazy consensus.
>
> i'm very pleased with the progress made (apologies that i haven't found
> time to be more active on this). i'd agree that it's about time for the
> site to go live. however, i'd probably recommend a VOTE (probably on
> something like 'are we ready to go live?'). you deserve to see all
> those +1's and messages of thanks...
[Tim O'Brien]
Yeah, Mark, thanks for all the work, and +1. I think this is ready to go
live.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [common-build]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 21 Mar 2004, at 22:12, Stephen Colebourne wrote:
>> yep, I think we are settled on the design in this area. So what are
>> your
>> sentimate on the overall toplevel site generation. Do you feel its
>> adequate to replace the existing contents at this time?
>
> I would say the time is right to update the main site. Then people can
> comment on it and it'll get fixed from there. A kind of lazy consensus.
i'm very pleased with the progress made (apologies that i haven't found
time to be more active on this). i'd agree that it's about time for the
site to go live. however, i'd probably recommend a VOTE (probably on
something like 'are we ready to go live?'). you deserve to see all
those +1's and messages of thanks...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [common-build]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> yep, I think we are settled on the design in this area. So what are your
> sentimate on the overall toplevel site generation. Do you feel its
> adequate to replace the existing contents at this time?
I would say the time is right to update the main site. Then people can
comment on it and it'll get fixed from there. A kind of lazy consensus.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [common-build]
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Stephen Colebourne wrote:
> All I have really done is to apply what I thought was the agreed standard to
> a number of projects. I did create the extra sandbox css file, but otherwise
> I've just been cutting and pasting.
And I think it all looks great, I think we all owe you a word of thanks
for your efforts in cleaning this up.
> As I understood it, the jsl was needed so as to get stuff below the maven
> doc block on current maven versions. I thought the dtd was just part of
> that.
Yes, the commons-site.jsl also maintains the css L&F across the whole
commons. I just actually think we can get away with even more global
control of the navigation menus via some small modifications to the jsl.
But, I also suspect some of this sort of automation can wait until we at
least get a beta release of the current site up and running.
>
> Instead of describing technical detail, I'll describe the site. In an ideal
> world I want
>
> Commons Xxx
> Overview
> User guide/History/Best practices/...
> Javadoc (latest release)
> Download (new page, links to download choices)
>
> Development
> Mailing lists (from maven)
> Team (from maven)
> Developers guide (code standards)
> Project status (formal proposal and status file)
> Tasks (todo list)
> CVS
> Javadoc (CVS latest)
>
> Project documentation (maven)
>
> [Other commons documentation]
>
> [Components menu]
>
> [Sandbox menu]
>
> [Related]
>
> Of course the top section layout is project dependent, but it would be nice
> to have some familiarity between projects if possible.
>
yep, I think we are settled on the design in this area. So what are your
sentimate on the overall toplevel site generation. Do you feel its
adequate to replace the existing contents at this time?
-Mark
>
> From: "Mark R. Diggory" <md...@latte.harvard.edu>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, March 20, 2004 8:17 PM
> Subject: Re: [common-build]
>
>
>
>>Yes, thats what I meant by the second item on the list. It was unclear
>>to me if we had achieved consistency across all the sub-project
>>navigation.xml docs at this point.
>>
>>Some thoughts:
>>
>>a.) Approach I was advocating was to use commons-site.jsl to control
>>navigation creation and ordering so that includes did not need to be
>>present in individual projects.
>>
>>b.) approach I believe your working on uses dtd includes directly into
>>navigation.xmls of subprojects.
>>
>>c.) Currently we have a hybrid of these two approaches, 1.) Includes
>>into each navigation.xml 2.) enforcement on ordering in commons-site.jsl
>>
>>Is this what we want? Can it be made more transparent to the
>>sub-projects by not using includes at that level?
>>
>>
>>[X] stable top level navigation.
>>[ ] agreed includes in all subproject sites (single include strategy).
>>[ ] backup of current toplevel site.
>>[ ] fresh rebuild and publish of mavenized top-level site (under
>>jakarta.apache.org/commons).
>>[ ] fresh rebuild and publish of all sub-project sites.
>>
>>-Mark
>>
>>Stephen Colebourne wrote:
>>
>>>Looks good, although I thought that we now had a single include strategy
>
> for
>
>>>subprojects.
>>>
>>>Stephen
>>>
>>>----- Original Message -----
>>>From: "Mark R. Diggory" <md...@latte.harvard.edu>
>>>
>>>>Whats our current status on the the top level site? I think its obvious
>>>>that we have at reached a LCD (least common denominator) on the
>>>>navigation for the time being. So I'm going to break down things into a
>>>>list of steps to get through for migration of the "commons" toplevel to
>>>>the mavenized site.
>>>>
>>>>[X] stable top level navigation.
>>>>[ ] agreed includes in all subproject sites.
>>>>[ ] backup of current toplevel site.
>>>>[ ] fresh rebuild and publish of mavenized top-level site.
>>>>[ ] fresh rebuild and publish of all sub-project sites.
>>>>
>>>>I think its important to get the top-level site in place fist before
>>>>verifying all the lower level sites are correctly rendered, this is
>>>>because all links currently lead back to
>>>>http://jakarta.apache.org/commons and it difficult to do things like
>>>>link checking because the old site always ends up in the navigation
>>>
>>>stream.
>>>
>>>
>>>>On that note, do we have any solid "linkchecking" tools available to
>>>>verify the integrity of the site?
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [common-build]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
All I have really done is to apply what I thought was the agreed standard to
a number of projects. I did create the extra sandbox css file, but otherwise
I've just been cutting and pasting.
As I understood it, the jsl was needed so as to get stuff below the maven
doc block on current maven versions. I thought the dtd was just part of
that.
Instead of describing technical detail, I'll describe the site. In an ideal
world I want
Commons Xxx
Overview
User guide/History/Best practices/...
Javadoc (latest release)
Download (new page, links to download choices)
Development
Mailing lists (from maven)
Team (from maven)
Developers guide (code standards)
Project status (formal proposal and status file)
Tasks (todo list)
CVS
Javadoc (CVS latest)
Project documentation (maven)
[Other commons documentation]
[Components menu]
[Sandbox menu]
[Related]
Of course the top section layout is project dependent, but it would be nice
to have some familiarity between projects if possible.
Stephen
From: "Mark R. Diggory" <md...@latte.harvard.edu>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, March 20, 2004 8:17 PM
Subject: Re: [common-build]
> Yes, thats what I meant by the second item on the list. It was unclear
> to me if we had achieved consistency across all the sub-project
> navigation.xml docs at this point.
>
> Some thoughts:
>
> a.) Approach I was advocating was to use commons-site.jsl to control
> navigation creation and ordering so that includes did not need to be
> present in individual projects.
>
> b.) approach I believe your working on uses dtd includes directly into
> navigation.xmls of subprojects.
>
> c.) Currently we have a hybrid of these two approaches, 1.) Includes
> into each navigation.xml 2.) enforcement on ordering in commons-site.jsl
>
> Is this what we want? Can it be made more transparent to the
> sub-projects by not using includes at that level?
>
>
> [X] stable top level navigation.
> [ ] agreed includes in all subproject sites (single include strategy).
> [ ] backup of current toplevel site.
> [ ] fresh rebuild and publish of mavenized top-level site (under
> jakarta.apache.org/commons).
> [ ] fresh rebuild and publish of all sub-project sites.
>
> -Mark
>
> Stephen Colebourne wrote:
> > Looks good, although I thought that we now had a single include strategy
for
> > subprojects.
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Mark R. Diggory" <md...@latte.harvard.edu>
> >
> >>Whats our current status on the the top level site? I think its obvious
> >>that we have at reached a LCD (least common denominator) on the
> >>navigation for the time being. So I'm going to break down things into a
> >>list of steps to get through for migration of the "commons" toplevel to
> >>the mavenized site.
> >>
> >>[X] stable top level navigation.
> >>[ ] agreed includes in all subproject sites.
> >>[ ] backup of current toplevel site.
> >>[ ] fresh rebuild and publish of mavenized top-level site.
> >>[ ] fresh rebuild and publish of all sub-project sites.
> >>
> >>I think its important to get the top-level site in place fist before
> >>verifying all the lower level sites are correctly rendered, this is
> >>because all links currently lead back to
> >>http://jakarta.apache.org/commons and it difficult to do things like
> >>link checking because the old site always ends up in the navigation
> >
> > stream.
> >
> >>On that note, do we have any solid "linkchecking" tools available to
> >>verify the integrity of the site?
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://www.hmdc.harvard.edu
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [common-build]
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Yes, thats what I meant by the second item on the list. It was unclear
to me if we had achieved consistency across all the sub-project
navigation.xml docs at this point.
Some thoughts:
a.) Approach I was advocating was to use commons-site.jsl to control
navigation creation and ordering so that includes did not need to be
present in individual projects.
b.) approach I believe your working on uses dtd includes directly into
navigation.xmls of subprojects.
c.) Currently we have a hybrid of these two approaches, 1.) Includes
into each navigation.xml 2.) enforcement on ordering in commons-site.jsl
Is this what we want? Can it be made more transparent to the
sub-projects by not using includes at that level?
[X] stable top level navigation.
[ ] agreed includes in all subproject sites (single include strategy).
[ ] backup of current toplevel site.
[ ] fresh rebuild and publish of mavenized top-level site (under
jakarta.apache.org/commons).
[ ] fresh rebuild and publish of all sub-project sites.
-Mark
Stephen Colebourne wrote:
> Looks good, although I thought that we now had a single include strategy for
> subprojects.
>
> Stephen
>
> ----- Original Message -----
> From: "Mark R. Diggory" <md...@latte.harvard.edu>
>
>>Whats our current status on the the top level site? I think its obvious
>>that we have at reached a LCD (least common denominator) on the
>>navigation for the time being. So I'm going to break down things into a
>>list of steps to get through for migration of the "commons" toplevel to
>>the mavenized site.
>>
>>[X] stable top level navigation.
>>[ ] agreed includes in all subproject sites.
>>[ ] backup of current toplevel site.
>>[ ] fresh rebuild and publish of mavenized top-level site.
>>[ ] fresh rebuild and publish of all sub-project sites.
>>
>>I think its important to get the top-level site in place fist before
>>verifying all the lower level sites are correctly rendered, this is
>>because all links currently lead back to
>>http://jakarta.apache.org/commons and it difficult to do things like
>>link checking because the old site always ends up in the navigation
>
> stream.
>
>>On that note, do we have any solid "linkchecking" tools available to
>>verify the integrity of the site?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [common-build]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Looks good, although I thought that we now had a single include strategy for
subprojects.
Stephen
----- Original Message -----
From: "Mark R. Diggory" <md...@latte.harvard.edu>
> Whats our current status on the the top level site? I think its obvious
> that we have at reached a LCD (least common denominator) on the
> navigation for the time being. So I'm going to break down things into a
> list of steps to get through for migration of the "commons" toplevel to
> the mavenized site.
>
> [X] stable top level navigation.
> [ ] agreed includes in all subproject sites.
> [ ] backup of current toplevel site.
> [ ] fresh rebuild and publish of mavenized top-level site.
> [ ] fresh rebuild and publish of all sub-project sites.
>
> I think its important to get the top-level site in place fist before
> verifying all the lower level sites are correctly rendered, this is
> because all links currently lead back to
> http://jakarta.apache.org/commons and it difficult to do things like
> link checking because the old site always ends up in the navigation
stream.
>
> On that note, do we have any solid "linkchecking" tools available to
> verify the integrity of the site?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[common-build]
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Whats our current status on the the top level site? I think its obvious
that we have at reached a LCD (least common denominator) on the
navigation for the time being. So I'm going to break down things into a
list of steps to get through for migration of the "commons" toplevel to
the mavenized site.
[X] stable top level navigation.
[ ] agreed includes in all subproject sites.
[ ] backup of current toplevel site.
[ ] fresh rebuild and publish of mavenized top-level site.
[ ] fresh rebuild and publish of all sub-project sites.
I think its important to get the top-level site in place fist before
verifying all the lower level sites are correctly rendered, this is
because all links currently lead back to
http://jakarta.apache.org/commons and it difficult to do things like
link checking because the old site always ends up in the navigation stream.
On that note, do we have any solid "linkchecking" tools available to
verify the integrity of the site?
-Mark Diggory
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [convert] conversion with default values
Posted by Ron Blaschke <ma...@rblasch.org>.
Hello Stephen,
Saturday, March 20, 2004, 2:13:21 AM, you wrote:
>> >to Integer. The trick is then to design a combination engine to allow
>> >StringBuffer to Integer by combining StringBuffer to String plus String
>> >to Integer.
>> Sounds interesting. Do you have already concrete ideas how such a
>> combination engine would look like? I have thought about converters
>> working together in a kind of chain, too, e.g. for String to Integer
...
>> These are all slightly different use cases that should be supported by
>> such an engine. What do you think?
SC> Ron Blasch had some ideas on how this might work. I've cced to see if he
SC> wants to comment.
Thanks Stephen. I'd really like to move convert forward, but received
very litte feedback to my last posts, so I thought nobody cared too
much.
I have:
- some ideas how the convert lib should look, which I think would also
solve the problems mentioned in this thread
- a working prototype of most of my ideas
- lots of enthusiasm to move convert forward
Stephen, how should we proceed? Would it be worth, and possible, for me
to get commit access? Or should I keep sending things to you and/or the
list?
Ron
--
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [convert]conversion with default values
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> >The ObjectToInt conversion isn't quite what I had in mind, although
> >interestingly the [convert] system does allow it. I want a system where
> >there is one converter for Number subclasses to Integer and one for
String
> >to Integer. The trick is then to design a combination engine to allow
> >StringBuffer to Integer by combining StringBuffer to String plus String
to
> >Integer.
> Sounds interesting. Do you have already concrete ideas how such a
> combination engine would look like? I have thought about converters
> working together in a kind of chain, too, e.g. for String to Integer
> conversion: first try a simple Integer.parseInt() and if this fails, try
> a Locale aware parsing that deals with formatted values. Or conversion
> of arrays or collections of one type into arrays/collections of another
> type: here the converter dealing with the iteration stuff should be
> independent of the converter handling the single elements.
>
> These are all slightly different use cases that should be supported by
> such an engine. What do you think?
Ron Blasch had some ideas on how this might work. I've cced to see if he
wants to comment. At present my only thought was to work based on the
percent value
Double to Number, value=80
Number to Integer, value=80
Double to String, value=20
String to Integer, value=80
A average of the two combinations gives the best route to take.
But I'm sure there's a better way ;-)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [convert]conversion with default values
Posted by Oliver Heger <Ol...@t-online.de>.
Stephen Colebourne wrote:
[snip]
>The ObjectToInt conversion isn't quite what I had in mind, although
>interestingly the [convert] system does allow it. I want a system where
>there is one converter for Number subclasses to Integer and one for String
>to Integer. The trick is then to design a combination engine to allow
>StringBuffer to Integer by combining StringBuffer to String plus String to
>Integer.
>
>Stephen
>
>
Sounds interesting. Do you have already concrete ideas how such a
combination engine would look like? I have thought about converters
working together in a kind of chain, too, e.g. for String to Integer
conversion: first try a simple Integer.parseInt() and if this fails, try
a Locale aware parsing that deals with formatted values. Or conversion
of arrays or collections of one type into arrays/collections of another
type: here the converter dealing with the iteration stuff should be
independent of the converter handling the single elements.
These are all slightly different use cases that should be supported by
such an engine. What do you think?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [convert]conversion with default values
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I comitted an updated version of the default converter and factory to CVS. I
felt that a common superclass was inappropriate as it was merely being used
for sharing code rather than a true inheritance relationship. I still need
to fix the tests to match.
The ObjectToInt conversion isn't quite what I had in mind, although
interestingly the [convert] system does allow it. I want a system where
there is one converter for Number subclasses to Integer and one for String
to Integer. The trick is then to design a combination engine to allow
StringBuffer to Integer by combining StringBuffer to String plus String to
Integer.
Stephen
----- Original Message -----
From: "Oliver Heger" <he...@med.uni-marburg.de>
> I created a patch in bugzilla (bug ID 27639) that implements a
> conversion that supports default values if either null values are to be
> converted or a conversion causes an exception. This conversion and its
> corresonding conversion factory are implemented as decorators so they
> can be attached to arbitrary other conversions.
>
> To get a better understanding for the convert2 codebase I tried to write
> a simple Object to Integer conversion. I ended up with a base class for
> conversions from Object to arbitrary types, which should simplify
> construction of concrete conversions and their factories. I think now I
> understand what you meant by "support of inheritence without bothering
> the registry". These base classes and the Object to Integer conversion
> classes are also in the patch file. I hope this is useful.
>
> Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org