Code Patterns using $names/$fields/$index and $values parameters

#1

Folks, In recent and soon to be released versions of tiddlywiki a number of widgets now use the parameter pairs $names $values, $fields $values and $indexes $values.

I have started this topic to ask how you use or may utilise this “parameterisation method”. Start a discussion to share how to make use of them to see;

  • See how people are using these
  • Contribute to understanding and ultimately improving the community support and documentation
  • Provide examples to help people using such patterns
  • Show when it may be superior to a simple set of let/vars/set name=value pairs, or not for that matter.

For example;

With these pairs a simple set of corresponding names/values or filters that generate these can be provided.

  • One condition is the pairs need to have a one to one correspondence, as a result you may need to provide a “when blank value”.

I believe this approach to parameters is only going to increase in future versions, and I don’t think “I am alone” in thinking this can be a little confusing to make use of.

  • This is different to passing parameters as keyword value pairs keyword=“value” or keyword:“value” we are more familiar with. Also called attribute value pairs.
  • It may be useful with some set or hardcoded cases, but what if a variable number of keywords are available, such as fieldnames on the current tiddler?
    • Or the keywords refer to a list of titles

I can see that such an approach may even be necessary in some causes but how can we;

  • Provide more guidance on their use?
    • Especially handing potentially empty values
  • Make use of this approach in novel ways
    • especially in the GenesisWidget
    • its relationship to other attribute value pairs in tiddlywiki and html
  • This was in part in response to a need to pass multiple and a variable number of parameters to to a widget or macro, but how do we do this?

Please share what you know with the community and let us start the conversation!

Extended potentials?

  • Could we make use of this to process keyword/value pairs into variable/value or variable/value pairs?
    • Or the reverse?
#2

I don’t know if this is the case for everyone but for me I understand this naming convention as an exception than a rule for Widgets. A Widget―which is a TW only thing―uses angle brackets to have it match HTML syntax. But to keep it from being confused with HTML it has the $ prefix.

For parameters however, I don’t see a technical reason to prefix them with a $ except for one:

A widget that utilizes parameters as dynamic name/value pairs. The example being <$action-sendmessage> which has parameters but any parameter not prefixed with a $ are used to attach values to the message.

{any attributes not starting with $} ― Multiple additional, optional named parameters that are attached to the message

Thus widgets that utilize such dynamic parameters would need to distinguish parameters from those dynamic ones and those the widget needs to function.

Oh, sorry. just realized you already covered what I had posted. Disregard.