[Pmwiki-users] notitle/header/footer question

[Patrick R. Michaud]

On Tue, May 11, 2004 at 04:52:32AM +0100, J. Meijer wrote:
> At some point in the evolution of pmwiki the notitle/noheader/nofooter
> directives were implemented as doublebracket syntax. This makes it easy to
> copy one page into another and have it show identically. However, I would
> have expected these directives to appear as checkboxes on the edit-form. So
> their availability is apparent and no additional syntax is required.
> They would then need to be stored as properties of the page, outside of the
> main text. That would reduce processing requirements for that part.
> When including a page, these directives would not be propagated by default.
> 
> My question: is the current behaviour deliberate?

IIRC, [[notitle]], [[noheader]], and [[nofooter]] were implemented 
around the same time I added [[include:]] and WikiGroups.  They seemed
to be related aspects of a common theme, and so it made sense that the 
syntax for each be similar as well.  Indeed, one the earliest uses of
[[include:]] was intended to allow authors to create shared pages
(e.g., headers) that could replace the default header with one defined 
by the shared page, and thus the directives could be placed in the shared
page such that they *would* be propagated to included pages.  (This
contrasts with the description above where included page directives
do not propagate.)

I figure it's much easier to explain to authors that the noheader/nofooter 
directives in the text of included/shared pages affect the including
page than it is to say that the checkboxes on the shared pages do so.
Once WikiGroups were implemented with GroupHeaders (and later GroupFooters),
it was natural that the directives should propagate.

Also, there are far more directives than just noheader/nofooter/notitle,
it continues on to nogroupheader, nogroupfooter, spacewikiwords, 
[[redirect:PageName]], and even other extensions that people have
requested/built such as [[nosidebar]] and [[nologo]].

To be honest, I don't think that using checkboxes for these properties 
really ever crossed my mind when I was designing the feature.  So 
although the current behavior is certainly "deliberate", I can't honestly
say I made a conscious choice between the two alternatives.  If I did
make a choice, it was for the reasons above.

However, looking at it in retrospect, I'm extremely GLAD that I
chose the approach I did, because I think it's easier and more flexible
in the long run:
 - While checkboxes may indeed work for noheader/nofooter/notitle,
   it can be really cumbersome for noheader/nofooter/notitle/nogroupheader/
   nogroupfooter/spacewikiwords (nosidebars/nologos/nogoogleads/norobots/
   redirect...), especially if a shared/included page such as a GroupHeader 
   or GroupFooter is then expected to set the property for a whole 
   group of pages.
 - The current model allows similar "property extensions" to be easily 
   added via Cookbook modules without having to worry too much about 
   conflicts/coexisting with custom edit forms, or figuring out how
   make sure the newly-defined property is properly exported across
   shared/included pages.
 - Although having checkboxes can indeed make the features' availability
   more apparent, it can also increase the learning curve and cognitive
   overhead for an author encountering an edit page for the first time.
   I'd think that if checkboxes were indeed used for these directives,
   they'd need to be placed in an "advanced features" section of the
   edit page, or as part of a separate "advanced edit page", to make
   things easier for new authors.  Plus, I don't think that noheader/nofooter
   are common enough operations to warrant a checkbox on every edit page.
 - Having these features as checkbox properties complicates
   non-browser-based editing apps such as PmWikiEdit and EmacsModes.

BTW, I figure that there's little difference in page processing time 
between the two approaches, or that the current method can certainly be 
optimized such that there is no difference if that ever becomes an issue.

Hope this answers the question sufficiently...?

Pm