by IWR Consultancy
 

The Frame

constructing a frame for your site

The frame consists of a directory containing a special webpage named frame.php, and various associated files. The function of the frame is similar to that of the templates used in mainstream CMS products, in that it determines the overall layout and appearance of all pages in the website. We use the term frame because the use of template in this context is actually a misnomer. Hyperframe also has templates, and these serve -in the correct sense of the word- as outlines on which to base new pages.

In Hyperframe, any changes to the frame will profoundly affect all existing site pages, and all new pages. A change to a template will only affect new pages based on that template, created after the template was modified. 

One of the key tasks for any developer setting-up a Hyperframe site will be to construct a frame for that site. This task is somewhat more complex than the creation of a typical webpage, but not drastically so. It only needs to be done once, per site. Because of the special notation used in some places, it is best done in a text editor, and not with the online tools. 

Note that we are not talking about Netscape frames. Hyperframe sites do not use the HTML frameset tag. I guess the similarity of naming  might lead to some confusion, or even misapprehension by standards purists here, but I feel that the frameset tag is so seldom used these days that it is acceptable to reuse the term.

To see what a frame contains, navigate to the frame/ directory of this sample site and examine its contents. The main component of each frame is frame.php. Incidentally this file is always named frame.php, but the directory holding it can in principle have any name, allowing for multiple frames to exist.  

The frame.php file

This is a standard php/HTML file, of which only the <head> and <body> sections are used by the system. The rest is ignored.

A typical <head> section might contain:

<head>
  <title>Hyperframe !CMS</title>
  <meta name="description" content="HTML pages, content managed">
  <meta name="keywords" content="content management, web frontend, html, pages">
  <META NAME="hf_doctype" CONTENT="HTML">
  <META NAME="hf_hide" CONTENT="">
  <meta name="Author" content="IWR Consultancy">
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <link rel=stylesheet href="<?php echo codedir ?>system.css" type="text/css">
  <link rel=stylesheet href="<?php echo framedir ?>frame.css" type="text/css">
  <script language=javascript src="<?php echo codedir ?>system.js"></script>
  <script language=javascript src="<?php echo framedir ?>frame.js"></script>
  <?php include_once plugin('menu'); ?>
</head>

The frame's head section in fact forms the definitive head section of all pages, with the exception that certain items in the calling page's own head section may modify or over-ride those in the frame.

An important addition in Hyperframe 4 is the call to the menu plugin (bolded) which must be present  if the cascading menu plugin is used in pages. (If you use your own menu code you can omit this)

The title is used on all pages, and is prepended to any title found on an individual page. This conveniently avoids the need to keep repeating the site's name in titles. Where a page contains no title. the frame title is used, with the first <Hn> tag's contents appended. This in most cases will give rise to an acceptable title string which characterises the page's content.

The frame's description meta tag is only used if the calling page contains no title. If the page contains a title, its own description is used.

The author content -and any other unspecified meta content- applies to all pages, regardless.

Several special hf_xxxx meta tags exist:

hf_doctype determines the <!doctype> declaration placed at the top of each rendered page. The possible values are: 
HTML (Default, HTML5)
HTML5
HTML4
HTML4T
HTML4F
-which should be self-explanatory.
To reiterate, any doctype declaration in the first line of the frame will be ignored, as will any in the calling page. The reason it's done like this, by the way, is that the online editor needs to know the document type, and it's simpler to use a variable of a known format than to scan the file for it. It also means that any extraneous doctype tags on imported pages will not affect operation.

Hyperframe does not support XHTML. This is not the problem it might seem for imported pages, since the majority of XHTML documents will display perfectly well as HTML5.

HTML4 support, which is mainly provided for easy import of legacy sites, includes switching the editor's semantics to generate the tags preferred by that standard. For example in HTML4 mode, the Bold  button will insert a  <b> tag, in HTML5 mode it will insert a <strong> tag.

hf_hide takes any of the values banner, top, left, content, right, bottom  comma separated, or the keyword all. It causes the relevant hf-[section] ID to not be displayed.  hf_hide can be used in the frame, or in the calling page. This is useful where pages contain very wide content, and need more space.

The frame body

The body section of frame.php defines the master layout of all page using this frame.

In this example from the Slate frame, we have a top banner, a top dropdown menu and a fixed lefthand bar containing an image. There is no righthand bar. Divs provide layout.  Although it's not apparent here, if you examine the associated frame.css file you will see that this frame creates fixed-width pages.

Since only one menu is used, the menu filename is given directly as 'tree.mnu'  -which file will be in the sitecfg directory. The dropdown attribute sets the behaviour to be that of horizontal menu bar, whilst the menutree and topmenu classes of the menu container determine the css sections (in frame.css) needed to make this work. 

<body>
<div class="hf_pagecontainer">
  <div id="hf_banner" >
    <h1>Hyperframe flatfile CMS</h1>
  </div>
  <div id="hf_top" >
    <div class="menutree topmenu" >
    <a class="menu_single" href="<?php echo siteroot ?>sitemap.php">Site Map</a>
    <?php menu('tree.mnu','dropdown');?></div>
    <div style='text-align:right'><?php widgets();?>&nbsp;</div>
  </div>
  <div id="midsection">
    <div id="hf_left" >
     <img src="<?php echo framedir ?>sidelogo.gif">
    </div>
    <div id="hf_content" >
      <!--CONTENT-->
    </div>
  </div>
  <div id="hf_bottom" >
   Powered by Hyperframe <br>
  </div>
  &nbsp;  
</div>
</body>

Another example, this time from the Tabula frame. This uses a three-column layout, although the righthand bar is presently empty save for a spacer. Layout is, as the name suggests, by way of the more traditional table method. If you examine the associated frame.css  you will see that it's a variable-width page which adjusts its size to suit the browser window.  A max width of 1400px is set, though, to prevent excessively long text lines when displayed on large screens. Where this width is exceeded, the content will automatically center itself in the browser window.

In this frame two menus are used, a smaller top 'quicklink' menu with the most often-used links, and a cascading side menu with all the links. To achieve this, the sitemenu function is called, as opposed to invoking the menus directly. When done this way,  opening a page with the '?menu=top' parameter will result in the top menu being the main one -which can be useful on fullwidth pages with  no sidebar.

<body>
<table class="hf_pagelayout">
<tr><td id="hf_banner" >
  <div float='left' align='left'><img src='<?php echo framedir ?>hylogo.png' align="left"></div>
  <div float='right' align='right'><span class='callout'>by IWR Consultancy</span></div>
</td></tr>
<tr><td id="hf_top">
  <div float='left' align='left'><?php sitemenu('top');?></div>
  <div float='right' align='right'><?php printbutton();?>&nbsp;</div>
</td></tr></table>

<table class="hf_pagelayout"><tr>
<td id="hf_left">
  <?php sitemenu('side')?>
  <hr width=90%>
</td>
<td id="hf_content" >
  <!--CONTENT-->
</td>
<td id="hf_right">
  &nbsp;
</td></tr></table>

<table class="hf_pagelayout">
<tr id="hf_bottom"><td >
  <p class='callout'>Powered by Hyperframe</p>
<td></tr></table>
</body>

In all frames, the structure is that of a set of regions bearing these css IDs:
ID: hf_banner - a top banner
ID: hf_top - a topmenu line
ID: hf_left - a lefthand bar
ID: hf_content  - the main content area
ID: hf_right - a righthand bar (if used)
ID: hf_bottom - a footer area.

Because these css ID's are referred-to internally by Hyperframe, they should always be present in any frame if the relevant area exists. You can use these predetermined IDs for styling purposes, or you can add as many IDs or classes as you like of your own.  Layout can be built using divs, tables or HTML5 document section attributes as preferred.

By the way, there's no doubt that the mere suggestion of using a table for layout will get the soapboxers ranting, but it's a fact that layout using divs is a much harder art to master, and that a trivial mistake in div-based layout is very likely to leave you with a styling disaster like overlapping text. So, we're not making any hard and fast rule on that one. Do what you are comfortable with, and remember that in the end it's a site which displays correctly, and not as a jumbled mess or as overlapping text, that matters. If the site text is unreadable, then compliance with the standards textbook is irrelevant. The main point here, I think, is that layout using nested tables is very bad practice, and is almost never necessary.

If you look at the Divvy frame, you will see an example of div-based layout but with table-like behaviour, which is possible in the latest release of css. In some ways this is the optimal solution, offering the predictable behaviour of tables whilst also complying with the latest standards. It is somewhat more verbose and complicated than either of the conventional methods, though. Bear in mind this won't work in older browsers, either.

Images in the frame:

A point to note is that images or media are loaded from the calling page's context, not the frame's context. Thus, images to be incorporated into the frame need to be either css backgrounds, or else need to be called with the special syntax : src='<?php echo framedir ?>filename' -which will load the image from the frame directory regardless of what that is called-  which is usually what is wanted.

The hf_content area contains a special tag, <!--CONTENT--> which must be exactly as shown. This is not a comment, but a placeholder for the individual page content within the frame. So far this is the only example of 'duck code' within Hyperframe, and I'd rather it were not there.. but this proved to be the simplest approach, so that's the way it is.

A frame has a subdirectory, menu_img which contains the small placeholder icons used in the lefthand cascading menu. Since it might be desirable to customise these for specific frames, it makes more sense for them to be bundled with the frame rather than with the menu itself.

The frame.css file:

The place you will likely do most customising is the frame stylesheet, frame.css. This has four sections: Global styles which apply to standard tags, styles which apply to the predetermined IDs mentioned above, styles applying to the lefthand menu, and styles applying to the top menu. Note that whilst you can do more or less what you like with the others, some elements of the the top menu styling are essential to its function, so test any changes here carefully. 

Automation:

The frame can contain any php or javascript code. A point to note if including php is that the execution order is system php code, php code in the calling page, then php code in the frame. Thus, values changed in the frame have no effect on those settings as far as the calling page is concerned. This is probably the reverse of what you would intuitively expect, so take note. Since javascript is executed by the browser after the page has been sent, this consideration does not apply there.


Recently Visited

Related Pages
Powered by Hyperframe