Grokbase Groups Turbine dev June 2003
Hi Henning,

After looking at the IntakeService the past couple of weeks I can only say
that I hope to have the numberValidations clarified and (at least for
myself) identified issues that could/should be addressed in a further
release > 2.3, let's take it in small steps :-)

No I don't have committer rights so I'll send the stuff to you, offline. I
could start by sending you the new files and do the diffs later, I have to
leave office in 15 mins so I'll do the diffs from home. Once the changes are
in, building and being tested I'll get round to enhancing the Intake docs
which are way out of date.


"Colin Chalmers" <> writes:
I'd like to check-in the changes I've made to the IntakeService as discussed
earlier on the List. The changes are numerous but relatively small.
Hopefully things should be a little clearer as to how it works and paves
the road for further improvements after 2.3 is out the door.
I'll give a quick run-down here as to the main things that been
added/altered. To whom should I send the new files/diffs??
As you don't seem to have any user-visible changes (necessary changes to the
intake.xml file), I'm all +1 on this.

If you have user visible changes, then I'm +0 unless you supply a
small "you must change this to get from there to here" file for the
docs. Then I'm +1 again. :-)

Intake is an area where every patch helps. I'm still pretty amazed how
someone could conceive such a strange piece of code that actually does
something. My first contacts with intake still make me shudder when I
think back...

So basically: I'm all for it. Do you have Committer right on the CVS?
If not, send the patches to me and I'll review and check in.


Reasoning behind changes:
I was experiencing difficulty in validating (specifically) numbers, found
the implementation of a number of validations to be unclear and found
duplication of code. The validation of numbers was based on using
for all number types. This has been seperated to support shorts/longs etc.
which now all subclass an abstract NumberValidator which in turn subclasses
an abstract DefaultValidator which as BaseClass contains all Rules/info
which are common to all Validators. StringValidator is therefore a subclass
of DefaultValidator and deals only with Strings as the name says.
UML diagram is available upon request.
1. package;
A) ShortField - to support Shorts
B) LongField - to support Longs
A) FieldFactory - to support afore mentioned new Fields
B) StringKeyField - deprecated
2. package;
A) BigDecimalValidator - extends NumberValidator and validates BigDecimals
B) DoubleValidator - extends NumberValidator and validates Doubles
C) FloatValidator - extends NumberValidator and validates Floats
D) LongValidator - extends NumberValidator and validates Longs
E) ShortValidator - extends NumberValidator and validates Shorts
F) StringValidator - subclasses DefaultValidator and validates Strings
A) DefaultValidator - Abstract Base class for all Validators
B) NumberValidator - Abstract class that extends DefaultValidator to deal
with number types
C) IntegerValidator - extends NumberValidator and validates Ints
D) FileValidator - extends DefaultValidator
I'd like to have these changes tested by others, welcome feedback and will
fix any probs should they emerge.

To unsubscribe, e-mail:
For additional commands, e-mail:
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH +49 9131 50 654 0

Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 5 | next ›
Discussion Overview
groupdev @
postedJun 10, '03 at 11:39a
activeJun 11, '03 at 9:00p



site design / logo © 2018 Grokbase