PERL CGI Beginners - One link to 2 frames

Author

One link to 2 frames

MNibble

2005-09-20, 6:57 pm

Aloha

is there a standard solution to this problem, by now i do this with a
javascript, but i want to change it.

Thanks for your time

MNibble

David Dorward

2005-09-20, 9:55 pm

On Tue, Sep 20, 2005 at 02:05:09PM +0200, MNibble wrote:

> is there a standard solution to this problem

To what problem? (Please don't depend on people reading subject
lines).

There are two:

1. Don't use
frames. http://www.allmyfaqs.com/faq.pl?Pro...th_using_frames

2. Link to a new frameset document.

Neither really involve Perl or CGI.

--
David Dorward http://dorward.me.uk

Bill Stephenson

2005-09-20, 9:55 pm

On Sep 20, 2005, at 7:05 AM, MNibble wrote:

> Aloha
>
> is there a standard solution to this problem, by now i do this with a
> javascript, but i want to change it.
>
> Thanks for your time
>
> MNibble

I think with CGI it would be to create, then send to the client, the
main html page which contains the frames you want the user to see.

Kindest Regards,

--
Bill Stephenson

Jimmy George

2005-09-21, 7:55 am

Hello MNibble

As a couple of other writers have said. Why are you using 'HTML FRAMES'
and JavaScript to load them?

Get a book on CSS and read it carefully. Then try a few things. Use
XHTML preferably and it is all done on 'the user side'. That one CSS
file can describe every page you want to have displayed - including
links. And you can have multiple css files on your site.

All you need to do is write that CSS file and then have each (X)HTML
page refer to one or the other of your CSS files. The one you need for
'THAT PARTICULAR PAGE'.

CGI should be kept for the server side manipulations of user data. Which
is secure.

The manipulation of FRAMES from CGI is a waste of time. And where I live
with a standard link speed of 1.2Kb/sec speed means a lot to me.

YES - No Broadband.

cheers from James

MNibble

2005-09-21, 7:55 am

Bill Stephenson wrote:
> On Sep 20, 2005, at 7:05 AM, MNibble wrote:
>
>
>
> I think with CGI it would be to create, then send to the client, the
> main html page which contains the frames you want the user to see.
>
> Kindest Regards,
>
> --
> Bill Stephenson
>

Thx both of you. But i realy think there musst be a possibilty. I have
two javascript funktions which i try to get rid of. The first is this
link which fills to frames ( i would also fork into two processes with a
redirect ... maybe that's gonna work )
and a time delay .. something like: if you are not in 30 sek then push
..... There i'm pretty much out of luck, this CGI just tells me that this
multipart CGI stuff only works for Netscape - which is no option. But
again, i'm willing to pull any stunt to get rid of javascript at that point.

with regrads
MNibble

David Dorward

2005-09-21, 7:55 am

On Wed, Sep 21, 2005 at 08:32:47AM +0200, MNibble wrote:

> Thx both of you. But i realy think there musst be a possibilty. I have
> two javascript funktions which i try to get rid of.

This started off as a simple case of populating two frames in response
to one user action (at least as far as I understood it). Now you've
introduced a stack of other elements into the equation, all of which
appear to be possible solutions to a larger, undefined problem.

If you specified what the actual problem you are trying to solve is,
you might get some advice that is more relevent to your situation. As
it is, we can only try to answer the questions you ask. (And the
answers you've recieved are good ones in the context of the question).

> The first is this link which fills to frames

There are two ways to do this.

1. Linking to a new <frameset> document
2. JavaScript

In most cases the better solution to the problem is eliminating the
frames and sending the user a single combined document.

> ( i would also fork into two processes with a redirect ... maybe
> that's gonna work )

One request returns one HTTP resource, that's how the web works. You
can't return one document, then return another document a little while
later, the client won't be expecting it.

> and a time delay .. something like: if you are not in 30 sek then
> push

It would be up to the browser to determine if they are "in" or not,
and that would require JavaScript. I've no idea why you would want
that functionality though. It sounds like a band-aid solution to more
serious underlying problem.

--
David Dorward http://dorward.me.uk

MNibble

2005-09-21, 7:55 am

Jimmy George wrote:
> Hello MNibble
>
> As a couple of other writers have said. Why are you using 'HTML FRAMES'
> and JavaScript to load them?
>
> Get a book on CSS and read it carefully. Then try a few things. Use
> XHTML preferably and it is all done on 'the user side'. That one CSS
> file can describe every page you want to have displayed - including
> links. And you can have multiple css files on your site.
>
> All you need to do is write that CSS file and then have each (X)HTML
> page refer to one or the other of your CSS files. The one you need for
> 'THAT PARTICULAR PAGE'.
>
> CGI should be kept for the server side manipulations of user data. Which
> is secure.
>
> The manipulation of FRAMES from CGI is a waste of time. And where I live
> with a standard link speed of 1.2Kb/sec speed means a lot to me.
>
> YES - No Broadband.
>
> cheers from James

I won't say you are wrong, since you are right.I (please don't throw
stones or bits at me) already use css und div span and stuff like that
and if it is called xhtml that's fine for me, but i have this one iframe
which has two frames in it. I know i can be done without this frame stuff.
The CGI stuff i use is for data preparation and mixing on other servers
and some databases. And since CGI is already in use, i like to draw the
page with it, this way i don't have to do to many nasty dirty html stuff.

Broadband is only a minor thread since, the 'web app' is for lan only.

Thx anyway

MNibble

MNibble

2005-09-21, 6:55 pm

David Dorward wrote:
> On Wed, Sep 21, 2005 at 08:32:47AM +0200, MNibble wrote:
>
>
>
>
> This started off as a simple case of populating two frames in response
> to one user action (at least as far as I understood it). Now you've
> introduced a stack of other elements into the equation, all of which
> appear to be possible solutions to a larger, undefined problem.
>
> If you specified what the actual problem you are trying to solve is,
> you might get some advice that is more relevent to your situation. As
> it is, we can only try to answer the questions you ask. (And the
> answers you've recieved are good ones in the context of the question).
>
>
>
>
> There are two ways to do this.
>
> 1. Linking to a new <frameset> document
> 2. JavaScript
>
> In most cases the better solution to the problem is eliminating the
> frames and sending the user a single combined document.
>
>
>
>
> One request returns one HTTP resource, that's how the web works. You
> can't return one document, then return another document a little while
> later, the client won't be expecting it.
>
>
>
>
> It would be up to the browser to determine if they are "in" or not,
> and that would require JavaScript. I've no idea why you would want
> that functionality though. It sounds like a band-aid solution to more
> serious underlying problem.
>

I didn't said that the answers where bad, or a least i didn't want to
sound that way ( english is not my mother tongue, so may be i didn't
reply 100% as i ment it).

You were right about the redirect ... i didn't know it before, but after
i tried i got: to many redirects.

The time delay, well yes there is a problem, but i can't fix that on, so
this needs to be my workaround. There a lot a data that needs to be
processed, and i didn't want the user to wait for that page, so i put a
side befor the output and give the data some time to settle.

I know that the question was a open on, but the answers were everything
i aspected, so i guess the question was OK, still not perfect.

Thanks for your time
MNibble

David Dorward

2005-09-21, 6:55 pm

On Wed, Sep 21, 2005 at 02:29:15PM +0200, MNibble wrote:
> The time delay, well yes there is a problem, but i can't fix that on, so
> this needs to be my workaround. There a lot a data that needs to be
> processed, and i didn't want the user to wait for that page, so i put a
> side befor the output and give the data some time to settle.

The trick here is that when a request comes in:

* Generate a unique ID for the job

* Fork it off into the background (or store the details in a database
and let a continuing background process handle it)

* Return to the user a page explaining that the process will take some
time and give them a link (including the job id) to check to see if
it is ready yet. Idealy you will provide some time estimate on the
issue. You can also use JavaScript or a meta refresh to periodically
poll the server without user intervention. This should be in
addition to the link as JavaScript is optional, and meta refresh
isn't standardised.

--
David Dorward http://dorward.me.uk

Sponsored Links