i.e.
map field names to validation types, required/not required, etc,
then when the data comes in iterate over the struct
for each field, get the validation type
call a function containing a switch that runs the error check for that validation type and returns an error or ""
The best thing about this approach is that it's scalable and reusable. But you're right about the lack of self-documentation.
then when the data comes in iterate over the struct
for each field, get the validation type
call a function containing a switch that runs the error check for that validation type and returns an error or ""
But mostly I would say that an object that takes that many arguments is probably doing too much. Or that the coder is hard-coding static configuration values that should be in an xml file somewhere.
Blair
On 4/3/06, Barry Beattie <[EMAIL PROTECTED]> wrote:
yep, and we have too on occasion. broken down functionality into more
logical bite-sized pieces.
the problem there is
- type checking and checking for empty/missing arguments. if it's a
bean being populated by a form it's all strings anyway so the type
checking is internal. can you imagine 150+ if StructKeyExists() and
isNumeric()/isDate() needing to be coded up inside the bean? icky....
- documentation. again, using a DTO bean as an example, having 3
structs and an additional single value or two tells you nothing about
what that bean needs if you brought it up in the CFC explorer.
I have been kicking the idea around of smaller sub-objects/beans that
still do the same thing as the smaller structs but encapsulating the
type/exists logic within them. instead of each struct having domain
over it's data (keys) it takes it further with validation.
The trouble there is you run the risk of disappearing up one's own
backside with smaller and smaller objects. Mandelbrot-set objects. the
more you look the more you find...
On 4/3/06, Shib71 <[EMAIL PROTECTED]> wrote:
> If a function needs more than a half dozen arguments I use a struct.
>
> Blair
>
>
> On 4/3/06, Barry Beattie < [EMAIL PROTECTED]> wrote:
> >
> I'm thinking of this from a code management/maintainance point of view.
>
> someone's got up to 50 and lived to tell the tale. more is possible.
>
> but is it practical? and what's the alternative?
>
> or just live with it? if the been/object/whatever needs 'em all just do it?
>
> anyone want ot share their experiances?
>
> thanx
> barry.b
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org ) and supported by CFXHosting (
> www.cfxhosting.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
> (www.cfxhosting.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
