<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
FWIW, this can be taken to an extreme, as I have done ('cause I'm
extreme I guess <grin>). See
<a class="moz-txt-link-freetext" href="http://parkcommons.ca/wiki/wiki.php?n=Help-Documentation.BrowserPageLayout">http://parkcommons.ca/wiki/wiki.php?n=Help-Documentation.BrowserPageLayout</a>.
I have the page laid out into 12 sections, many of which have both
defaults ("fallbacks" in Pm terminology) and over-rides resulting in a
set of (potentially) no less than 22 display blocks (read included
pages) for the page to select from. But that's because I want people to
be able make a variety of independent design choices in a complex farm
implementation, to buy me some time before I offer a bunch of different
skins.<br>
<br>
I don't recommend anything even approaching this for the core product,
but my point is that in the general scheme of things, adding one layer
to the core is a little bit arbitrary.<br>
<br>
My personal take on it would be to select something that is in priority:<br>
- simple<br>
- instructive<br>
<br>
The "fallback" approach is pretty instructive, but not necessarily so
simple. I generally find that common users want zero levels of
abstraction, and the group header is already one (two if you include
the edit layer as the first level of abstraction), leaving the fallback
as the second (or third). Plus there are potentially complex
considerations regarding the interaction between the choices.<br>
<br>
Option "2b" will probably be most accessible to most (separate
inclusion and exclusion for each), so that would be my favorite.<br>
<br>
People can always implement their own fallbacks/defaults/overrides with
(:include {*$Group}.Override {*$Group}.Default {*$Group}.Fallback:) (or
whatever) inside the group or site header.<br>
<br>
- Henrik<br>
<br>
Patrick R. Michaud wrote:
<blockquote cite="mid:20070618185404.GI11839@host.pmichaud.com"
type="cite">
<pre wrap="">On Mon, Jun 18, 2007 at 10:00:06AM -0400, Ben Wilson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Having combed through the recent message traffic, I see no clear
consensus. Is there a PITS where the various options can be listed and
voted/commented upon? There appears to be interest in _some_ site-wide
group (I join that crowd). However, the obvious problem lies in how it
is named.
</pre>
</blockquote>
<pre wrap=""><!---->
You're correct that there doesn't seem to be much consensus, but part
of that is due to confusion arising from the varying interpretations
available (which I failed to recognize in my original post).
So, I'll try to summarize the thread here, provide some options,
and we can all reflect on those. Also, to avoid having to say
things like "GroupHeader and GroupFooter" throughout the document,
I'll speak only of headers here with the understanding that the
same rules apply for footers.
Currently, PmWiki defaults to having a GroupHeader page in every
group; the contents of the group's GroupHeader page is automatically
added to the top of the page's markup when the page is displayed.
This is useful for having content automatically added to every page
in a group. There's also a (:nogroupheader:), which allows a
page to prevent the GroupHeader being added.
There are a couple of recipes that allow this capability to
be extended on a site-wide basis -- i.e., to have a special page
that is automatically added to the markup for all pages on a site,
as opposed to just within a group. I was looking to adopt one
of these as a PmWiki core default. As Ben mentions, there's
widespread interest in this.
There are two major models we can follow here, which I'll describe
below. Keep in mind that regardless of which model PmWiki chooses
as an out-of-the-box default, it will always be possible for a
site administrator to choose a different one.
-----
Option 1: A page that acts as a "fallback GroupHeader" when
a group doesn't have one. In this scenario, when viewing a page,
we first look for a page named GroupHeader in the current group,
if that exists we use it, otherwise we use the "fallback" page
if it exists.
A group that didn't want to use the fallback page would simply
create its own GroupHeader page. A group that wanted to add
markup from both the fallback page and the group's GroupHeader
would use an (:include:) directive to include the fallback page.
The (:nogroupheader:) directive would suppress the header text
altogether -- neither a per-group GroupHeader nor the fallback
page would be added.
There's substantial precedent for an approach like this one...
most skins display group-specific SideBar pages, and fall
back to Site.SideBar if a group-specific page doesn't exist.
-----
Option 2: A page that is automatically added to the beginning
of every page's markup, regardless of any group-specific GroupHeader
page -- i.e., a "site-wide header".
If this approach is taken, then there as question as to whether
the site-wide header should be affected by (:nogroupheader:),
or if it should have its own (:nositeheader:) directive.
If we use (:nogroupheader:) to control the site-wide header text,
it then becomes difficult for a group to suppress the site-wide
header.
If we introduce a separate (:nositeheader:) directive, then
there's a question (and potential confusion) as to the sequence
of processing -- should a group be able to suppress the site-wide
header with (:nositeheader:), or should the site-wide header be
able to suppress the per-group header with (:nogroupheader:)?
(We can't do both.)
-----
To try to add some further clarity, my use of the term "header"
here is meant to strictly refer to "markup that is automatically
added to the beginning of a page's text when it is displayed
using ?action=browse". I'm not referring to the masthead, logos,
title, or other items that are typically provided by a page's skin.
(But see my postscript below for a related topic.)
Along these lines, several people have suggested using the
name "PageHeader" instead of GroupHeader or SiteHeader, but
I'm *very* disinclined to do this. In the code and documentation,
PmWiki has consistently used the phrase "page header" to refer to the
portion of the skin template that appears at the beginning
of the <body> section of an HTML page. For example, templates
use <!--PageHeaderFmt-->, <!--PageLeftFmt-->, <!--PageTitleFmt-->,
etc. I don't want people to be somehow confused into thinking
that pages named "PageHeader" are somehow related to
<!--PageHeaderFmt--> in skin templates.
Similarly, I'm very disinclined to any proposals that
greatly increase the number of pages involved or that an
author might need to be familiar with to make things work.
So, rather than introduce a plethora of pages to try to handle
every conceivable situation, I'd rather keep the defaults
very simple and complexity for recipes for those who want/need it.
So, that's where I see things standing. What we have left to do
is to decide which option above (if any) we might consider using
as a PmWiki default, and then how to name the sitewide header
page so that it makes sense within that option.
Comments welcomed. I've put up a voting page at
<a class="moz-txt-link-freetext" href="http://www.pmwiki.org/wiki/Test/VoteOnSiteHeader">http://www.pmwiki.org/wiki/Test/VoteOnSiteHeader</a>
where people can indicate their preferences on the various
options available.
Thanks,
Pm
_______________________________________________
pmwiki-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:pmwiki-users@pmichaud.com">pmwiki-users@pmichaud.com</a>
<a class="moz-txt-link-freetext" href="http://www.pmichaud.com/mailman/listinfo/pmwiki-users">http://www.pmichaud.com/mailman/listinfo/pmwiki-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Henrik Bechmann
<a class="moz-txt-link-abbreviated" href="http://www.bechmann.ca">www.bechmann.ca</a>
Webmaster, <a class="moz-txt-link-abbreviated" href="http://www.dufferinpark.ca">www.dufferinpark.ca</a></pre>
</body>
</html>