Benefits / Problems using IFRAME

[rfr]

I have been using FrontPage 2003 Module Insert Page moderately successfully
for things
like header and footers for years.

But, in certain circumstances, the FP insert seems to include the WHOLE PAGE
again at the point where a simple module is inteded to be inserted. This
happens with certain pages more than others and does NOT happen all the
time. The non-consistent behavior \makes it nearly impossible to track down
the probem or to be sure the work-around that one implements does work.

I have used IFRAME in certain cases where the code is on another server.
This
seems to work well. There are certain differences;
1. IFRAME WILL pay attention to any header CSS or JS code, where FP INCLUDE
doesnt
2. IFRAME seems to be a bit more picky about definition of width and length
than FP INCLUDE
3. IFRAME has NEVER doubled up on me.
4. Page counters via CGI do not get incremented on IFRAME documents as
reliably as when FP INCLUDE is used. I dont know why.

Have any of you decided to switch away from FP INCLUDE PAGE and start to use
IFRAME instead?

Have any of you tried to switch to using IFRAME for includes but found
reasons shy this is not a good idea?

 

[Neredbojias]

Have any of you decided to switch away from FP INCLUDE PAGE and start
to use IFRAME instead?

Have any of you tried to switch to using IFRAME for includes but found
reasons shy this is not a good idea?

The optimal way is to use server-side includes. Anything else usually
'includes' problems of one kind or another.

 

[rfr]

If one does their web site authoring and development on their PC, as I do,
and developes documents on a stage-by-stage, visualizing basis, then using
server-side includes is not an option. Because it is not possible to
visualize the impact of server-side includes on documents created on ones PC
( unless one wants to run a full server on his PC).

Also, server-side includes change the way one names files from .htm or .html
to .shtml extensions, so that the server knows which documents to parse,
looking for includes.

Also, it is not possible for client-side mouse actions to influence which
modules are inserted when one uses server-side includes. However, with
IFRAMES it is possible with JavaScript to give the client options on what is
displayed in the IFRAME with a simple mouse-click.

What I was seeking with this IFRAME question is if other are finding
problems with IFRAME or limitations or benefits ?

I know one limitation that I have experienced and do not know why it happens
is this: the page counters on documents included in an IFRAME do not seem to
increment in a reliable way. Whereas, the same document do increment
reliably outside the IFRAME use.

I have heard that the search engines do not rank material inside IFRAMES as
high as if it were mainstream document material.

But, are there other limitations or benefits to IFRAME use?

 

[Neredbojias]

If one does their web site authoring and development on their PC, as I
do, and developes documents on a stage-by-stage, visualizing basis,
then using server-side includes is not an option. Because it is not
possible to visualize the impact of server-side includes on documents
created on ones PC ( unless one wants to run a full server on his PC).

Also, server-side includes change the way one names files from .htm or
.html to .shtml extensions, so that the server knows which documents
to parse, looking for includes.

Also, it is not possible for client-side mouse actions to influence
which modules are inserted when one uses server-side includes.
However, with IFRAMES it is possible with JavaScript to give the
client options on what is displayed in the IFRAME with a simple
mouse-click.

The preceding 3 paragraphs were rationalization, meaningless, and
erroneous, respectively.

What I was seeking with this IFRAME question is if other are finding
problems with IFRAME or limitations or benefits ?

Possibly, but what you asked was if using iframes for includes was a good
idea. My response suggested that it wasn't and there are better methods.

I know one limitation that I have experienced and do not know why it
happens is this: the page counters on documents included in an IFRAME
do not seem to increment in a reliable way. Whereas, the same document
do increment reliably outside the IFRAME use.

I have heard that the search engines do not rank material inside
IFRAMES as high as if it were mainstream document material.

But, are there other limitations or benefits to IFRAME use?

Perhaps you should have posted "What are the limitations of using iframes
for includes?" Of course Google would probably provide a larger selection
of answers (assuming a proper query.)

 

[Alan J. Flavell]

If one does their web site authoring and development on their PC, as

Do I take it that by "PC" you mean Windows? (PC hardware can also run
real operating systems, but I'll go along with the assumption that
you're talking about some recent-ish flavour of Windows).

I do, and developes documents on a stage-by-stage, visualizing
basis, then using server-side includes is not an option. Because it
is not possible to visualize the impact of server-side includes on
documents created on ones PC ( unless one wants to run a full server
on his PC).

Can't agree. Win32 Apache2 is quite easy to install, and can offer
an environment which is close enough to one's production Apache
(unix-ish) server for many practical purposes. I've got Apache2 on
my Windows laptop, and I definitely recommend doing it, if you aim to
do any serious web development on your peecee. Far more realistic
than trying to browse files directly in the filesystem.

You may want to configure it so that it can only be accessed from
localhost (or whatever range of local addresses you care to trust).

Also, server-side includes change the way one names files from .htm
or .html to .shtml extensions,

Not necessarily. Apache configuration is very flexible.

so that the server knows which documents to parse,
looking for includes.

Admittedly, the Win32 file system doesn't make this as straightforward
as the unix one, where the use of XBitHack with the file system's "x"
permission bits can do the trick; but you can configure server parsing
via a <Files...> bracket to target precisely the files which you wish
to parse.

Or you might be interested in
http://search.cpan.org/~rkobes/Apache-WinBitHack-0.01/WinBitHack.pm
although I haven't tried it myself. Obviously you'd need Perl
installed in order to use this.

There are other configuration possibilities. Up to you, really.