Nomads | Philosophy | Index
NOMADS: | IFrame-Host | IFrame-Host-Demo | Sic et Non | IFrame-Source | HowTo
The main use of iFrames has been for including media such as videos or music selections.
But you may wish to build a working page for some specific task, and then embed that page into another. This isolates the one page from the other for user-interactions, and from the Content Management System, which can be desirable, but it can also be the source of problems.
Working with the PmWiki framework -- {Snippets Pub} is built using PmWiki -- I found that it was easier sometimes to include outside pages as iFrames so that the guest page code does not conflict with the Content Mangement System (CMS) in this case, PmWiki. It also makes for an easy way to build functional pages with little or no regard to the appearance, which will be added by the surrounding/hosting page.
A good example of this is the user-login system, implemented here, which handles all login functions on a separate set of pages, which are hosted in a single iFrame, even though the "page" displayed changes depending on login status. The same Login Module (PmWiki calls it a recipe - or plug-in) can be used from different themes or skins usually without changing the code, since the CMS surrounds the iFrame with all the decoration and navigation features we want.
The dynamic part of this code came from developing a means of embedding an online shopping system within a PmWkiki website, where the embedded shopping pages changed size regularly.
Later on the Dynamic / Directory Audio Player was able to make very good use of the iFrame hosting project, since it's purpose was to provide an embeddable media-player, functionally stand-alone, but not requiring a whole web-page.
Notice that these applications meet several conditions:
________________
Do you have permission to include the content from the guest page in your host page?
Simply put, by hosting content from another page, you may be breaking Copyright / Intellectual Property permissions.
Be sure you have permission to place the content of the guest page on your host website!
________________
User Interface / User Access
Especially for alternative-access methods such as those used by people with disabilities.
By placing content in an iFrame, for some users it acts like requiring the user to go to a different page.
This may be exactly what you want, but often it is the opposite:
For a typical user, the content is all organized visually in the same space - on the same page; but for some users that visual organization does not exist!
To them, one part appears on one page, and the other part on a whole different page.
In the case of playing media, such as music or video files, that can work very nicely, which is why iFrames currently exist.
You need to be sure that the guest content, while for many people appears related to the host content, still makes sense when viewed as Stand-Alone content - as if it is on a whole different page.... which it really is.
________________
Location can break your functions:
- This code can work from two different locations, but it does not work the same as when both pages are in the same source location!
Case-1: both Host and Guest are accessed from the same place in the same way.
* Both Host and Guest are accessed from the same protocol, domain, sub-domain and on the same port:
— e.g. both pages hosted at https://www.mydomain.org, and also using the same port--e.g. 443, and the same protocol--e.g. https
— https://www.mydomain.org and https://music.mydomain.org will NOT work - they are different sub-domains.
Case-2: If any part of the page access differs,
— say http vs https, or www.mydomain.org vs www.yourdomain.org, or www.mydomain.org vs music.mydomain.org, or www.mydomain.org:443 vs www.mydomain.org:80
Modern browsers will not allow you to modify the Guest page by injecting the iframe_guest.js script.
Therefore you will need to add the iframe_guest.js code manually to your guest page.
Again, see the iFrame Host HowTo for complete instructions.