Did you receive the IntakeService patches I sent yesterday to your personal
email address?
There were two zip files in total, first the new files followed by the diffs
of the altered ones.
Let me know if there are any probs.
Colin
----- Original Message -----
From: "Henning P. Schmiedehausen" <hps@intermeta.de>
Newsgroups: hometree.jakarta.turbine.dev
To: <turbine-dev@jakarta.apache.org>
Sent: Tuesday, June 10, 2003 3:45 PM
Subject: Re: IntakeService
"Colin Chalmers" <colin.chalmers@maxware.nl> writes:
discussedI'd like to check-in the changes I've made to the IntakeService as
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 theHopefully 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??
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.
Regards
Henning
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
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
which now all subclass an abstract NumberValidator which in turn
an abstract DefaultValidator which as BaseClass contains all Rules/info
which are common to all Validators. StringValidator is therefore a
which are common to all Validators. StringValidator is therefore a
of DefaultValidator and deals only with Strings as the name says.
UML diagram is available upon request.
1. package org.apache.turbine.services.intake.model;
Added:
A) ShortField - to support Shorts
B) LongField - to support Longs
Changed:
A) FieldFactory - to support afore mentioned new Fields
B) StringKeyField - deprecated
2. package org.apache.turbine.services.intake.validator;
Added:
A) BigDecimalValidator - extends NumberValidator and validates
UML diagram is available upon request.
1. package org.apache.turbine.services.intake.model;
Added:
A) ShortField - to support Shorts
B) LongField - to support Longs
Changed:
A) FieldFactory - to support afore mentioned new Fields
B) StringKeyField - deprecated
2. package org.apache.turbine.services.intake.validator;
Added:
A) BigDecimalValidator - extends NumberValidator and validates
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
Changed:
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
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
Changed:
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
fix any probs should they emerge.
Colin
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
