On Sun, 16 Jun 2002 [EMAIL PROTECTED] wrote:

> Hello all,
>
> I have an interesting situation.... I have a series of web forms were the top
> half always has the same few entry boxes, checkboxes, radio select buttons
> etc... On the bottom half of each form there are always different entry boxes
> and other form-related fields. I am designing my cgi scripts that these forms
> get sent to and I do not want to have to copy the area of the script that takes
> in the default settings into every script (because it will be the same for
> all). If I make a change to any of the form fields in the default area then I
> will have to change the same areas of all the scripts. (I already know that
> each cgi script will have to be different in how it handles the bottom custom
> fields, I have accepted that). I want to have each custom cgi script call one
> side script to handle and check the default fields but I am not quite sure how
> to do this. Let me re-phrase that, I know how to effectively call a side script
> by using either the system() function or using $results = `script_name.pl` but
> that script I call has to know what the params where that were initially taken
> in by the "custom-field" cgi script that called it. Does any script that you
> call from the main cgi script know what all of the form fields were? Is there a
> way to pass that side script every form-field that was passed to the main
> script? Is the only option that I have is to get all the form info with the
> param() in the custom (main) script and make those arguments to pass to the
> side script that handles the default fields? Am I babbling at this point?
>

One way, admittedly a non-high tech way, is to handle the top part of your
forms in code that is included in each of the other scripts via a
"require". That way, the common code will only have to be maintained in
one place. Each time the any script is invoked it will "include" the
latest and greatest and common code for handling the top part of the form
and in addition you won't have to worry about any pesky interface code to
call the common logic or pass it parameters or any of the other stuff. The
"required" code will have direct access to all the form fields because it
will be in each of the "main" scripts. My suggestion would be to isolate
the code that does the top part of your forms from one of your customs
scripts, then extract it and put it into a separate file that all the
custom scripts "require". Depending on the particular logic of your
scripts it may not be practical to isolate all the "standard" code in one
file. It that turns out to be a problem then just use multiple "require"
files and have your custom scripts do multiple "require"s. Note, this
approach should work even if your scripts are implemented via mod_perl.

A slightly more radical and more high tech way of dealing with this
problem would be to "package" all the code for dealing with the top part
of your form into a module that then could have multiple methods for
dealing with the standard portion of the form. Then your custom code could
simply "use" the module and call the standard code for dealing with the
standard forms fields. This would allow maximum flexability in your
scripts in terms of where they invoked the code for handling the standard
fields. Both of these approaches would allow the code for dealing
with the standard form fields to be maintained in one place,
minimize any need for paramater passing or strange interface
code and virtually eliminate having to do anything special with the
custom modules whenever the standard form fields or the related processing
needed to be changed.

Of course all this is easy for me to say without knowing how either your
code or forms look and best of all not having to to do the actual
work to implement this change.

**** [EMAIL PROTECTED] <Carl Jolley>
**** All opinions are my own and not necessarily those of my employer ****

_______________________________________________
Perl-Win32-Users mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Reply via email to