[pmwiki-users] Using Page Text Variables {$:Var} for multi-line Includes

Pico pmwiki at ben-amotz.com
Tue Oct 10 08:21:52 CDT 2006


> From: Kathryn Andersen <kat_lists at katspace.homelinux.org>
> 
> On Tue, Oct 10, 2006 at 08:02:00AM -0400, Pico wrote:
> > Patrick R. Michaud wrote:
> > > On Mon, Oct 09, 2006 at 12:13:11PM -0400, Pico wrote:
> > >> Patrick R. Michaud wrote:
> > Another issue is that whenever I would want to define multi-line page 
> > text variables, I would *not* want the content to be hidden by default. 
> >   As a result, I would always use the directive form, and then call the 
> > page text variable to display it.  That does not seem like a great 
> > solution for drafting, rendering, or editing.
> 
> Agreed.  It does seem odd to link "multi-line" with "hidden".
> 
> On the other hand, we probably *do* want some form of hidden text
> variables -- but should we just use the (:if false:) method instead?
>  

Actually, I didn't mean to suggest that we get rid of the "directive"
form of page text variables, just that we use something else to deal
with multi-line text.  So (:var:text:) would continue to define a page
text variable without displaying its contents.  I assume that the
directive form makes sense for undisplayed variable definitions,
because directives are generally undisplayed.  

On further reflection, while I continue to like my suggestion of
allowing anchors to open and close multi-line page text variable
definitions for the uses I have in mind, I recognize that there would
be a great benefit to providing a multi-line form that is as simple and
straightforward as the regular single line form.  Right now, the
existing option of using a hidden directive format does not seem the
like the answer.

To get started, I'll just start with the most natural format that an
author would be tempted to try without special instructions and
prompting.

Name: Elmer Fudd
Phone: 123.456.7890
Address: Street
         City, State Postal Code
         Country

That looks natuaral.  It might even be possible to implement something
like this (if you use the white-space indentation rule as an allowable
extension). If it could be coded, it might still be tricky to use
(white-space indentation fails if text is not lined up exactly)

Or, perhaps definitional form may provide an acceptable compromise,
particularly if we bring Jr's markup extension for multiple definitions
into the core, which takes the form of :term::first
definition::additional definition

:Name: Name: Elmer Fudd
:Phone: 123.456.7890
:Address: Street 
::City, State Postal Code 
::Country


That could work (although it doesn't seem so natural, and if you were
tempted to indent the extra lines, you would break the code, at least
as it exists under Jr's recipe.  

How about a special paragraph style rule that is triggered when a colon
is followed by a carrage return, like this.

Name: Elmer Fudd
Phone: 123.456.7890
Address: 
Street 
City, State Postal Code 
Country

The content of the address variable would start after the first carriage
return and would end when a paragraph end is encountered: two returns
would be required to end the variable definition.  With this format,
the question arises as to whether the content should be returned as a
wrapped paragraph, or whether breaks should be inserted at the end of
each line.  There are advantages to each and perhaps the choice can be
left to the author who calls the variable.  If this was called in a
pagelist using the default form, I might want the multi-line text to be
wrapped like a paragraph.  Or I might not.  In either event, though, I
should be able to express my preference through the markup I use in the
template, or otherwise in a page that calls the variable, using
linebreaks directive.

A final thought.  The examples we are using (a multi-line address)
strike me as just bad practice: authors should be using a separate
variable for potentially separate lines, which can then be called
together, or on separate lines.  (But that does not help me with my
uses, which involve blocks of multi-line text with varying numbers of
lines).

Pico





More information about the pmwiki-users mailing list