[pmwiki-devel] handling of input arrays

Hans design5 at softflow.co.uk
Sat Nov 24 02:37:19 CST 2007


Friday, November 23, 2007, 11:18:15 PM, sti wrote:

> #   {$$field}
> #     When the value of the field 'field' is a single string, it is
> #     substituted in place. When the field is an array of values, then
> #     the value substituted is the same as if the replaced string had
> #     been {$$field[{$$foxtindex}]}. The value of {$$foxtindex} is the
> #     index of the current template being expanded, in the array of
> #     templates, starting with zero.

This is different from my current development version, where the index
is from the index of target pages, not templates. If the target field
is an array, other field arrays will be tied to it, including a template
field array.

> #   {$$field[num]}
> #     When the value of the field 'field' is an array, and 'num' is a
> #     number, then the element with index 'num' in the array is
> #     substituted. If the field is not an array, or if there is no
> #     such element, then the markup is simply removed. Note that when
> #     'num' is non-numeric, the markup is left unsubstituted, but do
> #     not rely on that, as further extensions may make use of
> #     non-numeric array indexes.

Good.

> #   {$$(function args...)}
> #     is replaced by the results of evaluating 'function' as if it
> #     were an ordinary Markup Expression (ie, as if it were the string
> #     '{(function args...)}' on a normal page). In order to provide
> #     backward compatibility, Fox.php adds a 'date' function to the
> #     list of valid markup extensions.

Yes. Fox is doing this lately.

> #   {$$field[]}
> #     The existence of one or more special markups of this form cause
> #     a special processing mode to be entered. For each element in the
> #     longest array named by this form in the template, a duplicate of
> #     the template is produced. The first duplicate contains all
> #     values of the 0th element of the named arrays, the second
> #     duplicate contains the 1st elements and so on. Missing elements
> #     are treated as null strings. All of the duplicates are written
> #     to the target, in order. The template can be broken into
> #     multiple sections with {[foxsection]} markers, each such section
> #     being treated independantly in this manner.

This is where I need most clarity. It looks like a good improvement to
the routine now in place. But I wonder: Shall the duplicated output go
to the same page, or to different target pages? Or can we have both,
so that a target array suggests a serial target mode, writing to each
target in turn, whereas the absence of a target array would trigger a
single page mode and arrays are processed as you describe.

> I discovered that it was necessary to split the template and handle the
> {$$var[]} cases first, as I found myself writing things like this:

>   {[foxsection]}
>   {$$(if (test equal {$$foo[]} {$$bar[]}) "Same" "Different")}
>   {[foxsection]}

> And I needed the sections to be generated before the {$$(if...)} was expanded.

To clarify:  {[foxsection]} markers are use to divide a template
into sections, and each section will be processed in turn, i.e. the
template engine goes through each section doing any variable expansion
as necessary? So basically you are allowing multiple templates to be
used, in turn? Sounds great!

> # FoxList
> #
> # handles {$$(list opt=xxx $$foo -$$bar -"foo" +bar ... )}
>.....
> This allowed me to write PTVs that would allow translated versions of the same
> blog entry to reference each other:

>  Versions: {$$(list $$langtarget -{$$target} sep=", " pre="[[" post="]]")}

This looks very interesting!



Hans




More information about the pmwiki-devel mailing list