Re: Targeting two frames from one CGI

drieux Sun, 08 Jun 2003 08:15:44 -0700


On Sunday, Jun 8, 2003, at 06:16 US/Pacific, Greenhalgh David wrote:
[..]

My question is this, How do I get the CGI to output one set of data to the left frame and then rerun a different CGI with the main frame as the target?

Dave


Oh this is never as easy as it looks..... If anyone ever
mentions to you that working with frames is not easy, they
are trying to be polite.... Or their Prozac is still working.

The term you need to feel at home with is

        what is a FrameSet and why do I want to use
                them when organizing frames...

How I solved this problem, since I have a similar problem,
where there is a "left frame" with vert_nav information,
and a 'right frame' with the main_page, that is again
devided into a main_head section and a main_data section
is to write 'pass through' CGI code...

at the top of the stack I have an index.cgi code which
if called without a query string will generate a simple:

libex: 52:] GET http://jeeves:12347/HqAdmin/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>Web Tool on jeeves</title></head>
<frameset border="0" cols="135,*" frameborder="no" framespacing="0">
  <frameset border="0" rows="97,*" frameborder="no" framespacing="0">
    <frame name="HqIcon" scrolling="no" src="html/icon.html">
    <frame name="VertNav" src="L1/L1_VertNav.cgi">
  </frameset>
  <frame name="MainBody" src="L1/L1_MainBody.cgi">
</frameset></html>
libex: 53:]

but if called with a query string would be say:

libex: 53:] !!"?callForm=Frodo&verb=shire" GET http://jeeves:12347/HqAdmin/"?callForm=Frodo&verb=shire"; <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html><head><title>Web Tool on jeeves</title></head> <frameset border="0" cols="135,*" frameborder="no" framespacing="0"> <frameset border="0" rows="97,*" frameborder="no" framespacing="0"> <frame name="HqIcon" scrolling="no" src="html/icon.html"> <frame name="VertNav" src="L1/L1_VertNav.cgi"> </frameset> <frame name="MainBody" src="L1/L1_MainBody.cgi?callForm=Frodo&verb=shire"> </frameset></html> libex: 54:]

Notice the Difference in the frame for the MainBody,
it actually has the query string attached to it. It is
up to the L1/L1_MainBody.cgi to resolve the details
as to what gets painted into the head and data sections.

So that you can see this in a progression, what happens
after the user has dealt with the 'level one stuff' we
send them off to deal with things at the next level:

libex: 56:] GET http://jeeves:12347/HqAdmin/L2/"?callForm=Bilbo&verb=ring"; <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html><head><title>Level Two</title></head> <frameset border="0" cols="135,*" frameborder="no" framespacing="0"> <frameset border="0" rows="97,*" frameborder="no" framespacing="0"> <frame name="HqIcon" scrolling="no" src="../html/icon.html"> <frame name="VertNav" src="../L2/ L2_VertNav.cgi?callForm=Bilbo&verb=ring&config_host=xanana&sysname=HqCon figdOpsOnly"> </frameset> <frame name="MainBody" src="../L2/ L2_MainBody.cgi?callForm=Bilbo&verb=ring&config_host=xanana&sysname=HqCo nfigdOpsOnly"> </frameset></html> libex: 57:]


Notice in this case we want to repaint BOTH the VertNav
section and the MainBody section with what ever were
the arguments we passed through in the query string.

I have not mentioned the HqIcon 'frame' - because,
well, it's Merely a Freaking Icon, and it just has
to sit there and look all corporate! Nothing interensting.

But it also helps us with the basic form of the problem
you described - three frames, one of which is constant,
a 'left navigation space' and a Main data section.

The astute observer will also notice that on top of
the basic query string that we called the 'L2' index.cgi
we have additional arguments in the query string

        config_host
        sysname

which are things that were 'resolved' at that level
and added into the mess that has to be passed along through
for my 'level 2' section to work.

What I did to 'solve' the problem was create a function

    v_Frame_Page($qString,
        "Level Two",
                "../L2/L2_VertNav.cgi",
                "../L2/L2_MainBody.cgi" ,
                "../html/icon.html"
                );

eg:
sub v_Frame_Page($$$$$)
{
        my ($qString, $title, $src1, $src2, $icon) = @_;
        
        if ( $qString)
        {
                $src1 .= "?$qString";
                $src2 .= "?$qString";
        }

        my $p = $DOC_TYPE .
                '<html><head><title>' . $title . '</title></head>' . "\n" .
                '<frameset border="0" cols="' . $COL_SIZE .
                        ',*" frameborder="no" framespacing="0">'. "\n" .
                '  <frameset border="0" rows="' . $ROW_SIZE .
                                ',*" frameborder="no" framespacing="0">' . "\n" .
                '    <frame name="HqIcon" scrolling="no" src="' .
                                $icon . '">' . "\n" .
                '    <frame name="VertNav" src="' . $src1 . '">' . "\n" .
                '  </frameset>' . "\n" .
                '  <frame name="MainBody" src="' . $src2 . '">' . "\n" .
                '</frameset></html>' . "\n" ;

\$p;

} # end of v_Frame_Page

This way I know that the Frameset I send to the browser
will always be set up correctly every time I use that
method, and I have abstracted it to what I need.

Yes, there are three 'global variables' that we use
in that module, for the DOC_TYPE, the COL_SIZE and ROW_SIZE.
But otherwise it is up to the player to pass in what they
want at each call....


What this allows me to do is write simpler cgi code. The
top level index in that tool is merely:

my $request = $ENV{'REQUEST_METHOD'};

my ($page_type, $page) = ("text/html");

  if( defined($request) && $request =~ m/^POST|GET|HEAD$/)
  {
        my $queryString = ($request eq 'POST' )?
                                <STDIN> : $ENV{'QUERY_STRING'};
        my $host = hostname;
        
        my $main_body = 'L1/L1_MainBody.cgi';
        if ( $queryString )
        {
                #
                # this isolates the contamination to only
                # the calls to the main-body function, IF
                # we were called with a callForm....
                #
                my $qs = no_window_QueryString($queryString);
                $main_body .= "?$queryString"
                        if ( defined($qs->{callForm}));
        
        }
        $page = v_Frame_Page('',"Web Tool on $host",
                                'L1/L1_VertNav.cgi',$main_body,'html/icon.html');
  }else{
        ($page_type, $page) = hq_web_invalid_request_page($request);
  }

make_header_and_send($page_type, $page);


The 'no_window_QueryString()' returns me a reference to
a hash that is the 'key/value' pairs of the query string
but without the "window" element - some browsers will
send you the *.x and *.y values that the mouse klicked
on an 'image button' and the like jazz, which in this
case is NOT useful to me, nor to any of the underlying
code - and in this case, we ONLY want the 'main_body'
to deal with any 'additional query string' data - and
not the vertical navigation section...
{ the rest of it is merely a matter of defensive
coding to whine if someone calls me with anything
but a POST, GET or HEAD method... }

The Level 2 index is a bit more funky - but basically
the same sort of thing:


    my $queryString = ($request eq 'POST' )?
                                                <STDIN> : $ENV{'QUERY_STRING'};

        my $calledFor='';
        
        my $formAction = {
                goodVerb  => \&HappyPlace,
                otherVerb => \&OtherPlace,
                sillyVerb => \&SillyPlace,
                homeBase  => \&HomePlace
        };
        if ( $queryString )
        {
                my $qs = default_query_hash({
                                sysname => "HqConfigdOpsOnly",
                                config_host => "BadConfigHost"
                        },
                        no_window_QueryString($queryString)
                );

                #
                # by default we expect to be call with HqConfigHome
                # we may not need all of these YET.....
                #

$page = SanityCheck($qs);

$calledFor = $qs->{callForm} || '';

$queryString = url_packer($qs); $page ||= ( exists($formAction->{$calledFor}) ) ? $formAction->{$calledFor}->($queryString) : defPage($queryString); } else { $page = hq_web_generic_error_page ( "Major Problem, Called without any arguments", "Please Check How Did You Get Here?<br><a href=\"../\">Go Back To Home</a>?" ); }

The big trick in this is that we have a hash of
functions - so that based upon what "form" was "called" -
the 'callForm' we will let that function resolve what to
do with those details...

We have a SanityCheck() method that makes sure that
the things in the query string are safe, sane, and sober...

For your purpose, a part of what you will need to work
out is the basic method calling model you want to use.

In my case I pass around that

callForm=<verb>

in the query strings to know where to 'go next' as it were...

This way I can have several different CGI code in a given
directory, and leave the basic process of filling up the
frames to 'index.cgi' and this basic model...

Each directory then has at least

        a. index.cgi
        b. Vert_nav managing cgi
        c. Main_data managing cgi

and other pieces of CGI code that are the worker bee's
for that level of the problem....

HTH.


ciao
drieux

---


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Targeting two frames from one CGI

Reply via email to