[pmwiki-devel] handling of input arrays

sti at pooq.com sti at pooq.com
Sat Nov 24 10:09:58 CST 2007

Hans wrote:
> 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.

I'm not sure its really different. Right now we have one template per target,
so its hard to say if my foxtindex is an index of targets or of templates. I
was thinking of it as a template index, but one could argue that its just as
much a target index.

>> #   {$$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.

I've put in the code for this, but I've never actually tested it, as I haven't
needed this feature.

>> #   {$$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 played with the idea of allowing one to associate multiple targets and
multiple arrays so that one might say:

(:input hidden target[] "A,B,C":)
(:input hidden template[] "W":)
(:input hidden target[] "D" :)
(:input hidden template[] "X,Y,Z":)

And this would allow you to specify that template 'W' would be used to write
to pages A,B, and C, while target 'D' would be written to by templates 'X','Y'
and 'Z' in turn.

I started doing some of the internal work to support this, and then decided
that maybe it wasn't the best approach, so I stopped until I found an actual
need for it.

>> 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!

Yes, its for cases when some of the information in the template needs to
appear only once, and some of it needs to appear as many times as there are
entries in an array.

>> # 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!

Thanks. I'm not 100% happy with what I had to do to get a MarkupExpression to
recognize $$variables. I gather that PM is thinking about some way to add new
categories of variables to the core, so things like ParseArgs and FmtPageName
can handle them cleanly. In the meantime, I just ended up making the internal
fields list be global.

I've sent you the code for what I've done, as messy as it currently is. Oh,
and I just realized I send it 'AS IS' which means I probably have some
debugging shims inserted for some testing I've been doing.

More information about the pmwiki-devel mailing list