On Fri, 14 Oct 2005 [EMAIL PROTECTED] wrote:
I have written a CGI Perl program that allows my users to view
relevant data.
The data is produced by a Unix application command and I have told it
to write to a intranet page that looks like:
What it looks like is irrelevant. The raw HTML is a little bit relevant,
but the really relevant thing is the data that gets sent to the script
and the results that are expected to be returned from the script.
What I want to do now is create a link using CGI Perl for each H
string that will pull a different data set either on a new page or on
the same page embedded.
Originally I just created another radio button for the new data set,
but there will be 6 different views (6 different strings) and I
already have 7 buttons (minus the Tape-Capacity button) and I do not
want to "button out" myself or the users.
I looked in the CGI Programming with Perl and saw an entry in there on
page 269 referencing access.conf and in access.conf you enter a line
with
Action Tracker /cgi/track.cgi
Can anyone help?
I'm sorry, I'm confused by the question.
You seem to want help organizing how data is presented to and retrieved
from the user of your web application, but then you're asking a CGI list
how to go about doing advanced Apache web server configuration. How was
the access.conf suggestion supposed to help solve this problem?
IF the answer to your problem is to start mucking around with Apache
directives -- and so far I'm not convinced that it is -- then putting
those directives in access.conf is outdated advice anyway. Modern Apache
administration tends to have people put everything in httpd.conf so that
there's one file to look in; some people break things into separate conf
files that httpd.conf includes, but this generally isn't how it's done
by people just getting started with Apache administration now.
In any case, it isn't clear to me how this was supposed to solve your
problem to begin with. What were you hoping would happen if you changed
the behavior of /cgi/track.cgi in Apache? I think you're better off just
concentrating on your HTML and CGI code for now, and leave mucking with
the web server for later.
Reduce the problem to a flow of desired inputs and outputs. The inputs
are generally going to be forms in plain HTML documents or as generated
by the output from CGI scripts; the outputs will generally be generated
from CGI scripts, though in some cases could be static HTML, too. You
may want to sketch things out on paper rather than just blindly start
coding things. If some part of the input system is doing too much or is
too confusing for users or maintainers, then break it apart as needed.
You seem to be asking general systems design questions without giving
enough material to clarify what the system is doing now or how it is
supposed to be working differently in the future. This is only
tangentally a CGI question; your first priority here seems to be to sort
out exactly how this is all supposed to be interoperating in the first
place. Once you have a clearer sense of that, implementing the specific
components of the system should get easier for you.
--
Chris Devers
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
