On 23/06/2009, at 10:34 PM, David FOXWELL wrote:
Checking that a field has only characters A-Z is not dependant on a
client, so I suddenly had the following brainwave :
Create a new module.
Copy Barbara's code into a function like CheckClientName or
something. For a company name I'll add CheckCompanyName and change
the constant containing the accepted characters.
Close but could be better. If the only, or major, code difference is
the constant for comparison then do it more like this:
New procedure: validateName( validateThis : withThat )
This has the body of the code and performs the validation giving a
result that indicates whether validation was successful (this could be
simple TRUE/FALSE or a number indicating the position of the first
invalid character in which case 0 would be all OK). This procedure MAY
be exported but I probably wouldn't do that. This will be a private
procedure used only within the module.
New procedure: validateClientName( name )
calls validateName( name : CLIENT_CONSTANT )
New procedure: validateCompanyName( name : CLIENT_CONSTANT )
calls validateName( name : CLIENT_CONSTANT )
Any special-case code can be placed in the parent procedure. Any
common name validation code goes in the private procedure.
Export validateClientName and validateCompanyName and add to the
binding source for the service program.
Profit from the simplicity of this module to persuade the boss to
let us integrate it as our first service program.
Excellent. But don't start by cloning code.
I'm already realising, however, that the names of the functions and
the module aren't that easy to think up, bearing in mind that it
could be used universally.
So putting Client into the names of the functions might not be a
good idea. What about the module name? I have to respect a rule of 3
characters and 3 numbers. Should I call it CHR000 or STR000 or TXT000?
That just sucks. You can guess what I think of that naming convention.
I see others have written on this so I'll leave it alone except to say
try to get this changed too--at least for module names and service
programs.
What you name the module will depend on how you view the modules
functions. Generic functions are easy: DATETIME, STRING, MATH,
FINANCIAL, STATISTIC, TRIG, etc. For business applications you might
break modules by department: GENLEDGER, ACTPAY, ACTRCV, ORDENT, etc.
In this case decide on where validateCLientName and
validateCompanyName belong. Perhaps together in some general purpose
name-handling collection, or perhaps you'll have a CLIENT service
program and a COMPANY service program--obviously with other related
functions. So decide on the modules responsibility--that will help
with choosing an appropriate name.
Even if you decide to put them in a single service program now you can
move them later. This will be easier if you use a binding directory
but would still require a rebind of any consumer. Better to think
about how these will be used in future and plan for it now rather than
have to live with the result of a bad decision.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
