FANDOM


Posting around 5 December 2014 by Yaron Koren:


Hi all,

Version 3.0 of Semantic Forms has been released. Functionally, this is a medium-sized release in terms of its changes, but conceptually it's a pretty big leap, which I thought justified the jump in version number.

Since the beginning, Semantic Forms has been a spinoff extension of Semantic MediaWiki - down to its name - and has required the presence of SMW to work. That is now no longer the case; SF can run without SMW. (Whether it would actually be a good idea to run SF without SMW is of course a different story!)

In terms of functionality, SF didn't actually require SMW for that much: just the special properties "Has default form", "Page has default form", "Has alternate form" and "Creates pages with form". (Though SF of course makes considerable use of SMW in other ways, including setting the right input type, doing autocompletion, etc.) "Has default form", when applied to a category or namespace, and "Page has default form", when applied to a page, can now be replaced by the new parser function #default_form; or by setting the form in the page schema, if one is using the Page Schemas extension. And "Has default form" and "Has alternate form" when applied to a property, in order to have red links point to a form, can now be replicated by replacing the relevant property tag with a call to another new parser function, #formredlink.

As for "Creates pages with form", it has no counterpart at the moment in a non-SMW system. Mostly that's because "Creates pages with form" seems to have started leading to a lot of problems with more recent versions of MediaWiki, and I didn't want to encourage the usage of it until it was fixed (which it hasn't been yet).

If SMW is not installed, there are a few features that no longer show up: those special properties would be gone, of course, and so would the special pages Special:CreateProperty and Special:CreateClass. The other special pages (CreateTemplate, CreateForm, CreateCategory) would still work, though for the first two cases with more limited functionality.

Why am I doing this, and why now? First, I'm not a big fan of special properties. I came to the conclusion a few years ago that parser functions are almost always a better option than special properties: they cause less aggravation for non-English languages; they allow for better display, and they allow for error-checking. I just don't think SMW's strength is in storing application-specific data. (It's the same reason why Semantic Drilldown no longer makes use of special properties as of its most recent version, 2.0.) Second, various people have asked about being able to use SF independently of SMW; so, given that the special properties were the only real reason to require SMW, I felt like it made sense to fulfill that request. (There's at least one more reason, but it's outside the scope of this email.)

So, on to the specifics - this version has the following changes and additions:

- There are two new parser functions. The first, #default_form, takes in one (unnamed) parameter, which is a form name. It can be placed in any page, template, category page or "namespace page" (i.e., the page at Project:NamespaceName), and it will lead to the "edit with form" tab showing up for the correct page or set of pages. (The one exception is that there's now no way to have the "edit with form" tab for a single category page itself, since #default_form in a category page will be interpreted as pertaining to the pages *within* that category. But I believe this is an extremely minor issue.)

- The second new parser function, #formredlink, is very similar to

  1. formlink; the main differences is that, if you specify the "target="

parameter, it links to a form only if that target page doesn't exist; if the target page does exist, it will simply link to that page. (The only other difference is that has a more limited set of allowed parameters.)

What about "alternate forms"? You can specify those within #formredlink simply by adding parameters that look like "alt_form[0]=<form name>", "alt_form[1]=<form name>", etc. On my wiki, discoursedb.org, for instance, you can now find the following calls:

...and, for a list:


- Of the extensions that define additional Semantic Forms form inputs, Semantic Maps is the only one I know that specifically requires Semantic MediaWiki. For that reason (and because of the importance of map inputs in general), SF now defines its own separate map input types, also called "googlemaps" and "openlayers". These are initialized only if Semantic Maps is not installed.

- Handling of the "mapping template" parameter was significantly improved: it can now be set for inputs of type "combobox" and "tokens", not just "dropdown", "checboxes" etc. Also some bug fixes were made for it. Thanks to Cindy Cicalese for these improvements.

- Various improvements were made to form parsing; the most important effect of these is that Special:RunQuery can now be embedded again in regular pages - this was something that a lot of people complained about before. Thanks to Masin Al-Dujaili and Stephan Gambke for these fixes.

- Semantic Forms can now be installed via Composer, in the manner of SMW, Semantic Result Formats and various other extensions. Thanks to Jeroen De Dauw for this addition.

- There were various other bug fixes; thanks to Ike Hecht, jme and Stephan Gambke for these.


As always, you can read more about Semantic Forms, including how to download it, here:

https://www.mediawiki.org/wiki/Extension:Semantic_Forms

-Yaron

Semediawiki-user mailing list
Semediawiki-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-user

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.