Example for what I want to achieve
I have many patch pages ("Patch 1.4", "Patch 1.5" etc.) that list the changes that were made to a project, where the affected/changed things are linked to their corresponding pages ("confirmation dialog", "foo", etc.):
Patch 1.4
Fixed spelling in the [[confirmation dialog]]
Patch 1.5
Added two options: [[foo]], [[bar]]
On the pages about the things that were changed ("confirmation dialog", "foo", …), I want to automatically show all corresponding changes:
Foo
[[Patch 1.5]]: Added two options: [[foo]], [[bar]]
Semantic MediaWiki’s subobjects can do this
#subobject allows me to create an (anonymous) object for each change on the patch pages:
{{#subobject:|
|Changes=Added two options: [[foo]], [[bar]]
|Affects=Foo|Bar
}}
And on each page ("foo" etc.) I can include an #ask subobject query to list all the matching subobjects:
{{#ask: [[Affects::{{FULLPAGENAME}}]]
|? Changes
}}
Great.
Problem: I have to duplicate the change entry.
On the patch pages, a change entry looks like this:
* Added two options: [[foo]], [[bar]] {{#subobject:|
|Changes=Added two options: [[foo]], [[bar]]
|Affects=Foo|Bar
}}
So I have to specify "Added two options: [[foo]], [[bar]]" two times: one time for the visible content, one time for the invisible subobject.
Is there a way in (Semantic) MediaWiki to do this without having to duplicate the content?
The ideal solution would just require me to enclose the change entry and specify the affected pages next to it, e.g.:
* {{ Added two options: [[foo]], [[bar]] }}((foo|bar))
As each patch page can list hundreds of changes, I don’t want to have to create a separate page for each change.
If I understand your question clearly, it seems you just need a simple query:
{{#ask: [[-Has subobject::{{FULLPAGENAME}}]]
| ?Changes
| format = ul
| headers = hide
| mainlabel = -
}}
Since using SMW markup may be tedious and error-prone, you might also use MediaWiki templates. You can simplify adding patch changes:
Template:Change
<includeonly><!--
-->{{#subobject:|
| Changes = {{{1|}}}
| Affects = {{{2|}}}|+sep=;
}}<!--
--></includeonly><nowiki/>
{{{1}}} and {{{2}}} are positional parameter,s and the Affects subobject property uses the ; separator (as a pipe | is ambiguous and may break templates, parser functions, etc). The <nowiki/> is a sort of a hack saving from whitespace bloating at the call-site pages.
You can also add a special template that would encapsulate the changes query:
Template:Patch changes
<includeonly><!--
-->{{#ask: [[-Has subobject::{{{1|{{FULLPAGENAME}}}}}]]
| ?Changes
| format = ul
| headers = hide
| mainlabel = -
}}<!--
--></includeonly><nowiki/>
By default, the template asks for the changes list for the current page (if the positional parameter #1 argument is empty), or you can explicitly override it at the call-site later (say, {{Patch changes|Patch 1.5}}).
Patch 1.4
{{Change | Fixed spelling in the [[confirmation dialog]] | Confirmation dialog}}
{{Patch changes}}
Patch 1.5
{{Change | Added two options: [[foo]], [[bar]] | Foo; Bar}}
{{Patch changes}}
respectively.
These links might be useful later:
SMW subobjects and queries
SMW standard parameters for inline queries
SMW templates
MW templates anonymous parameters
Related
I'm creating a blog just to dump my notes in. I love how far I can go with site.tags and site.categories. All I really need now is the ability to have another filter option. Something li site.sublog it would help me create exactly what I need
So here's a post
---
layout: post
title: "Angular.js With Codeschool:part five"
date: 2015-05-14 07:57:01 +0100
category: [Angularjs-codeschool, basics]
tags: [angular with codeschool]
sublog: [web]
---
Basically I want to write notes on everything I am interested in: web, general tech, history ... and sort of create sub blogs
There are ways around it but now that I am here I just wanted to know if such a thing was possible
Categories and tags are treated specially by Jekyll, so you won't find that other front matter entries from a post will be collected into a site-wide variable like site.categories and site.tags are.
The Jekyll documentation has a tutorial on retrieving items based on front matter properties, which shows how to iterate over an entire collection and do some per-item processing based on a front matter variable's value.
You could iterate over your collection, inspecting the sublog values of each item and concat-ing them to a list of all known sublog values (perhaps removing duplicates using uniq afterwards, and optionally sort-ing them before further processing).
This would enable you to create a list of all sub blogs, and for each sub blog, create a list of posts within it (which is presumably your end goal).
You can store Sitewide information + configuration settings in _config.yml.
Your example shows Page specific information in the YAML front matter!
Read the Jekyll Documentation, please.
I'm using an existing role, and I wish to modify it to extend its capabilities. Currently, one of its tasks is to create directories. These directories get passed as a variable containing a list of strings to the role, and then iterated over in a with_items statement. However, I would prefer to pass a list of dictionaries of the form e.g. {name: foo, mode: 751}.
So far so good; I can simply edit the role to make it take this sort of input. However, I also want to make it backwards compatible with the old format, i.e. where the items are strings.
Is there a way to test the type of a variable and then return different values (or perform different tasks) based on this? Perhaps using a Jinja2 filter? I was briefly looking at the conditionals listed in the manual, but nothing caught my eye that could be used in this situation.
You could use default() for backwards compatibility.
- file:
path: "{{ item.name | default(item) }}"
mode: "{{ item.mode | default(omit) }}"
state: directory
with_items: your_list
If the item has a name property, use it, else simply use the item itself.
Same goes for all other properties you might have in your dict. The special variable omit would omit the whole option from the task, as if no mode was passed to the file module. Of course you could set any other default.
Documentation references:
default
omit
The quickest solution would be to have two tasks, and have they trigger with opposed conditions. Unfortunately, all items in the list will have to use the same form (you can't mix and match strings and dicts).
- name: create dirs (strings)
file:
...
with_items: items
when: string(items[0])
- name: create dirs (dicts)
file:
...
with_items: items
when: not string(items[0])
Is it possible to have predefined values on a template? I.e.
{{Infobox Employee
|age = {{{age}}}
|gender = {male,female}
|occupation = {nurse, doctor, caretaker}
}}
So whenever someone uses this template they have to chose either male or female and if neither is chosen nothing shows. Very much like a select in html.
In core MediaWiki, you can make the template output an error or ignore unexpected parameters but cannot prevent the user from entering an invalid value. E.g. you can do something like this in the infobox:
{{#switch:{{{gender}}}
| male = Male
| female = Female
| #default = <span style="color:red">Invalid gender</span>[[Category:Pages with invalid template parameters]]
}}
(This example uses #switch from the ParserFunctions extension. You can do the same thing without ParserFunctions but it requires some complex and awkward template code.)
With the TemplateData extension you can specify allowed values, but it will only affect editors which rely on TemplateData (e.g. VisualEditor); it won't influence what someone can do with the template by plaintext editing.
The Semantic Forms extension can display an actual form for editing the infobox, with select boxes and whatever else you specify.
Folks,
I'd like to have similar set up to the one discussed in this question
Can I use templates to form a set of variables that I can then later include in various points in my wiki pages.
so for example have varables in my single template called MAIN_WEB_URL and MAIN_TEAM_DISTRIBUTION_LIST that I can store in a single template and reference site-wide where needed.
I'd like to avoid a template per variable if possible, but the other question seems to imply this is the only way to do it...
One way to do this would be to create a template called something like Template:Variable. In it, you would use one big {{#switch}} that would contain the variables and their values (this requires the ParserFunctions extension):
{{#switch: {{{1}}}
| MAIN_WEB_URL = some value
| MAIN_TEAM_DISTRIBUTION_LIST = another value
}}
You would then call it like this:
{{variable|MAIN_WEB_URL}}
(BTW, I am not a fan of ALL_CAPS names and I think there is no reason to use them here, but that's up to you.)
Is there a way I can create a database from which to pull data into my mediawiki table? Or is there a way to have a database like drupal and place a mediawiki type interface on it?
There is no way to directly do this in stock MediaWiki, although you can fake it up somewhat with templates. For example, you could can a template something like this:
{{#switch:{{{key}}}
| key1 = value1
| key2 = value2
| key3 = value3
...
}}
Template:NUMBEROF/data on the English Wikipedia is an example of this style (with two levels of keys).
Or you can create a set of templates, one for each "record", that each take an "output formatter" template as a parameter and pass that output formatter a named parameter for each column in the record. The Country data templates on the English Wikipedia are an example of this pattern.
Or you could combine the above two styles, with one parameter to select the row (as in the first style) and a second to provide the output formatter (as in the second).
If you don't mind installing extensions, you could use the Labeled Section Transclusion extension to transclude sections of a data page. Or you could install the Semantic MediaWiki extension, which I hear allows all sorts of querying of data from the wiki's pages. Or you could install one of the many Database extensions that may allow you to do what you want. Or you could write your own database extension.
You could also have a look at http://www.mediawiki.org/wiki/Extension:Data_Transfer, which do not require Semantic MediaWiki even though it's written for use with SMW. (If you use SMW there are, as noted in an earlier reply, plenty extensions and built in options.)