Template:Sm-sep-aa/doc

Sm-sep-aa

Semantic MediaWiki - Set Separator - Allows value.

-- pending name change: Sm => Smw.

Target

Workaround to get SMW's "Allows value" feature to work nicely with SMW's #Set Separator feature.

Wiki Doc Links

Semantic-mediawiki Allows_value

Semantic-mediawiki #Set Separator_parameter

Semantic-mediawiki Special_properties

Limitation/Features.

Will take care of leading and trailing spaces in inner data. (up to 2^N spaces. see process point 2)

Will convert text spaces into underscores in the final string.

Encountered wiki problems

1) Although, with the following input text "  foo,  foo bar  ,bar  " and code {{#set: property=<input-text>|+sep=,}}, the leading and trailing spaces on "  foo,*" and "*,bar  " are ignored/skipped. The same is not the case with the other spaces in the initial input string.

ie: SMW processes the text "*,  foo bar  ,*" as parameter " foo bar " with those leading and trailing spaces.

2) Although most MediaWiki parts tend to strips, or ignore, those additional leading and/or trailing spaces on the target parameters. SMW "Allows value" feature is not.

ie: With Allows-value's: "foo", "bar" and "Foo bar", this "foo  ,  foo bar  ,  bar" fails all three cases.

3) MediaWiki support for dealing with spaces is very limited (intentionally). And although converting spaces to some other character is possible. Converting them back to true spaces-characters before its piped back into the SMW-Set command seems/is not possible.

ie:   might display on screen as a space, but SMW-Set is actually getting the & nbsp ; string. (with <nowiki></nowiki> resulting in all the text inside the nowiki tags being ignored(not seen) by SMW)

Process (inner to outer chain)

0) Unconditional process. (#if checks are of no real use here. Makes for nasty code to)

1) Replace space character with some uncommonly used character. (this is now the alternative space character)

2) Compress multiple spaces. (4 spaces limit, can be extended to 8 by adding a additional replace level)

3) Ditch spaces next to used delimiter character (left and right case)

4) Turn left-over spaces into underscore character. (makes most sense in this case)

5) Pipe final result into SMW #set command with used separator.

Notes

(pending new code testing and implementation)

It turns out this leading/trailing spaces trouble is only related to using any other value delimiter than the "|" character.

- This leading/trailing spaces trouble only seems to directly effects value validation on properties that use the [[Allows value::value]] feature.

The only #set: variation that is working free of potential space troubles is the {{#set: Property | value1 | value2 | etc }}

In this particular case the property name can't have a "|" delimiter in front of it, or it will trigger a "" property name warning/error.

Intended solution. Pre-replace comma's for bars in the value's string. (if this works, it also allows (if needed at some point) for a different user-input value delimiter.)

Crap. The particular habits of the #set command in relation to the processing of named-variables makes the above solution seemingly impossible.

Basically the #set: command sees, and processes, named-variable strings as atomic/quoted input strings.

ie: {{#set:{{{input|}}} }} with input data abc|def|ghi act the same like one would write {{#set:foobar}}.

Although the +sep= parm will force the #set: command to reprocess the input data as intended, it also brings back the spacing problem (even with "|" as delimiter)

... Not sure if the MediaWiki Subst feature might open up some solution, but that's outside my current knowledge base.

Condensed test info/data

- any "property = value" variant has a potential leading spacing problem on that first value.

- any variant not using the "|" delimiter on values has potential leading and trailing spacing problems on all values.