Page MenuHomePhabricator

#arraymap separator insertion after occurrence of variable
Closed, InvalidPublic

Description

I've got this arraymap in a template:

{{#arraymap:{{{Type|}}}|,|VariableValue|[[Type::VariableValue]]: {{#show: VariableValue | ?Type name}} }}

With three items in the "Type" parameter, it produces an output that looks like this:

CCT30: Panda, CCT228: 1995 1 oz silver panda, CCT260: Fake panda,, , ,

Where CCT30, CCT228, and CCT260 are the values for the "Type" parameter, and the text strings after their colons are the output from the #show query.

I'm guessing the extra commas at the end are produced because the code looks to insert a comma after each occurrence of the variable, which is named "VariableValue" in this case. That's just a guess though.

You can view this result here:

http://www.coincompendium.com/wiki/index.php/CCT29
User: Demo
Password: test

Also, the documentation for #arraymap is very sparse. I think I'm using it correctly, if perhaps not how it was intended. This is all I could find for documentation:

http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Semantic_Forms_and_templates


Version: unspecified
Severity: minor

Details

Reference
bz32817

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:01 AM
bzimport set Reference to bz32817.

It seems like you forgot the "var" parameter - and you might be better off using the #arraymaptemplate function anyway. Setting this to "invalid".

Reopened. From the docs:

{{#arraymap:value|delimiter|var|formula|new_delimiter}}

the "var" parameter is named "VariableValue", in my above case.

From the docs, it appears to me I have used the formula correctly. In this case, the "formula" is:

[[Type::VariableValue]]: {{#show: VariableValue | ?Type name}}

It's very simple, and I don't see how that can be improved by using a template. Maybe I misunderstand the brief documentation. Examples would be helpful, in that case.

I marked this as "minor" since everything still seems to be working fine, even with extra commas hanging around. Here's another example:

http://www.coincompendium.com/wiki/index.php/Category:CCT10

I might see if I can get rid of them with some parser function string processing.

Ah - right you are; your #arraymap call was correct. Those extra commas are instead coming from the two subsequent #arraymap calls in your template. I'm setting this to "invalid" again.

Reopening again. In this page:

http://www.coincompendium.com/wiki/index.php/CCT29

You are correct that some of the extra commas are coming from the other arraymap calls, but that's just the same bug happening again. The other two arraymap calls are not supposed to produce any output at all, and they still finish off with an extra comma. No commas (delimiters) are going into the arraymap call, but it's still producing them.

I can't see how this could not be a valid bug. Look at the arraymap calls. There's nothing about them that is supposed to produce superfluous delimiters. If it's not a bug, then maybe it's some undocumented feature or other phenomenon I'm not aware of, but I can't imagine how those extra commas would be useful when the call isn't supposed to produce any visible output at all.

Example:

{{#arraymap:{{{Type|}}}|,|VariableValue|[[Category:VariableValue]]}}

[[Category:VariableValue]] should not produce any output, and it doesn't. It's the bug that's responsible for it. Also:

{{#arraymap:{{{Type|}}}|,|VariableValue|[[Type category::Category:VariableValue| ]]}}

contains:

[[Type category::Category:VariableValue| ]]

note the pipe and the space at the end of that. No visible output should be produced. Is there something I'm missing?

Yes, you're missing something - the optional last parameter, "new_delimiter". By default it's a comma, but it can be set to anything else, including blank. I'm setting this back to "invalid".

It would have been helpful if you had mention that critical fact. Why did you not say it? It would have save some hours in this debugging process.

At first it appeared the feature is actually a bug, since it produces output when none is required. Also, the new delimiter parameter cannot be used to output a comma and space like this:

{{#arraymap:{{{Type|}}}|,|VariableValue|[[Type::VariableValue]]: {{#show:
VariableValue | ?Type name}}|, }}

Even though that is the default new delimiter output when nothing is specified includes a space after the comma, when done like this:

{{#arraymap:{{{Type|}}}|,|VariableValue|[[Type::VariableValue]]: {{#show:
VariableValue | ?Type name}} }}

or like this:

{{#arraymap:{{{Type|}}}|,|VariableValue|[[Type::VariableValue]]: {{#show:
VariableValue | ?Type name}}}}

note the whitespace at the end, which was present only for readability, is
(properly) ignored by #arraymap, and was removed in the above example.

I tried using the C escape sequence \s to produce a space after the comma in the new delimiter parameter, like this:

{{#arraymap:{{{Type|}}}|,|VariableValue|[[Type::VariableValue]]: {{#show:
VariableValue | ?Type name}}|,\s}}

But that does not work. Further research shows that PHP (the underlying language) does not appear to have an escape character for a space:

http://php.net/manual/en/language.types.string.php

However, it DOES work with HTML entities, as described here:

http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

and used like this:

{{#arraymap:{{{Type|}}}|,|VariableValue|[[Type::VariableValue]]: {{#show: VariableValue | ?Type name}}|, }}

So, the default new delimiter is presented in the documentation as being optional, when actually it is not in the case where no output is expected. I will leave this bug report marked as invalid, and I will update the documentation with the information I have tested about how the #arraymap parser function works.