Last modified: 2013-06-10 03:39:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T39899, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 37899 - [SMW] 1.8; SMW_QP_List.php template enhancements
[SMW] 1.8; SMW_QP_List.php template enhancements
Status: RESOLVED INVALID
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Unprioritized enhancement (vote)
: ---
Assigned To: MWJames
:
Depends on: 37721
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-24 14:19 UTC by MWJames
Modified: 2013-06-10 03:39 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description MWJames 2012-06-24 14:19:22 UTC
* Don't assume a separator, allow access to params['sep'] within the template 
* Escape template $listsep with a separated <span> tag in order to be able to mark/filter those elements if necessary 
* Allow params['userparam'] to be available in IntroTemplate/OutroTemplate
Comment 1 MWJames 2012-06-24 14:54:54 UTC
* Put a div tag around the whole output
Comment 2 MWJames 2012-06-24 19:56:14 UTC
* If a template is being used for output, don't use any outside separators because the template should take care of the formatting itself.
Comment 3 contrafibularity 2012-08-03 12:59:13 UTC
I'm not sure if this needs a separate bug report (maybe this is addressed in MWJames' second request above?). The issue is that sometimes multiple values in a printout statement are not correctly parsed in the template, as reported here: 

http://semantic-mediawiki.org/wiki/Help_talk:Template_format#Sep

The problem occurs whenever a value contains commas (e.g. "York, Ontario"). The list of values passed to the template itself contains commas so that it becomes impossible for the arraymap function to distinguosh between them.
Comment 4 contrafibularity 2012-08-03 13:43:12 UTC
For historical reasons, I should add that there has been some discussion about this, but nothing has come from this, apparently. See bug 22777

https://bugzilla.wikimedia.org/show_bug.cgi?id=22777
Comment 5 MWJames 2012-08-03 13:52:25 UTC
I will not work on this for a while, I do have patch (somewhere) but their are other pending changes for SRF 1.8 which have a higher priority therefore anyone who feels he/she can tackle this enhancement, please go ahead. 

If someone goes ahead with the change, please ensure that parameter "sep" is used instead of itemsep as proposed in bug 22777.
Comment 6 contrafibularity 2012-08-03 18:48:17 UTC
Do you mean that once the old "sep" is abandoned, as you propose (because there's little need for it), it can be replaced with the "itemsep" under the name "sep"?

Just now I realised that there's also the Array format, which according to the SMW docs, 

"is used to format query results in a way most suitable for further processing by MediaWiki templates or parser functions". 

Whatever that means (templtes? parser functions?), it offers a number of specialised separators, such as "sep", "propsep" and the sep requested here, "manysep". 

As a non-developer, I'm just putting this out here, but maybe some of the code for the Array format could be incorporated?
Comment 7 MWJames 2012-08-03 19:13:39 UTC
No this is not what I meant. I did not suggest to abandon(nor something has been deprecated) any parameter rather to consider existing solutions that uses similar approaches just like the [1] where a template inclusion does transfer the "sep" into the template output.

If might a bit more confusing for a non-developer but for example looking at [1] method initTemplateOutput shows how "easy" it is to transfer the |sep parameter into the template output.

[1] https://gerrit.wikimedia.org/r/#/c/17165/3/formats/incoming/SRF_Incoming.php
Comment 8 MWJames 2013-06-10 03:39:49 UTC
Well, whatever I had planned in doing here has already outlived its purpose therefore closing this one.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links