Well, I have no real objection to such an extension getting created -
whether or not anyone used it, it wouldn't affect the rest of the
software. However, it doesn't seem important enough, in my opinion, to
get a slot in the Google Summer of Code - especially since, whether we
go through the Wikimedia Foundation or get accepted ourselves, I'm
guessing that we won't get that many projects - maybe three if we're
lucky. On a practical level, I just don't think there will be that
many cases where complex rules will be helpful; this is based on my
own experience using forms, as well as the questions and requests I
hear from users. It's true that rule-based functionality is still
getting added to Semantic Forms - the latest was "values dependent
on", which was just added in the last version. But "values dependent
on", i.e. having one input's allowed values be dynamically set based
on another's value, was something that quite a few people had asked
about - and it was actually something that I had wanted myself, for
use on discoursedb.org, since pretty much the beginning. The same goes
for "show on select". But beyond that, I just haven't heard, I don't
think, of that many additional needs for rules. The example you have
of a form field that holds the title not being editable, if the page
already exists, is interesting - and actually, I think I recall people
having asked about such a thing (though I'm personally not sure if
it's a good idea - what if someone renames the page and wants to
change that field?). But in general, I'm not aware of a widespread
demand for behavior in forms that SF can't address, that would call
for a general rule-based framework like this one.
By the way, Markus's suggestion of using Lua instead for the syntax is
interesting - I don't know how much simplicity that would add, since
of course SF doesn't use Lua either. (It might make sense for SF to
start using Lua, especially for things like handling the looped
template fields that might replace multiple-instance templates, but I
can't imagine how that would be done at the moment.)
One other possibility would be to use the structure provided by the
Page Schemas extensions instead:
At the moment it's still not getting widely used, I don't think, but
my hope is that it will, especially as new users come in and see the
benefit of creating all forms through it. It lets you define
additional data for fields, templates or the whole form, so it could
definitely house any rule-based information you wanted. And via the
"EditSchema" page, it can provide helpful, translateable, inline help
for filling in the data, so it might make things easier for admins
trying to create rules.
On Mon, Feb 13, 2012 at 7:42 AM, Markus Krötzsch
> Just a short reply: It would be good to have some such formalism, but
> designing a good language is not easy and would introduce another
> programming-like formalism into MW. I think one should seriously
> consider the upcoming LUA support to solve this problem . It would be
> much preferable to have a single scripting language being used for all
> MW in-page programming tasks.
>  http://www.mediawiki.org/wiki/Lua_scripting
> On 13/02/12 12:03, Stephan Gambke wrote:
>> for some time now I have thought on how it would be possible to get
>> away from introducing yet another new parameter every time a new type
>> of dynamic behavior is built into Semantic Forms. With the upcoming
>> GSoC 2012 I would like to discuss what I have come up with and if it
>> finds enough support would propose it as a project for GSoC.
>> Currently dynamic behavior of Semantic Forms is achieved by adding
>> additional parameters to inputs (or by having dedicated inputs). This
>> is a good approach where the dynamic behavior only concerns one input.
>> Autocompletion would be an example. It becomes awkward when more than
>> one field is concerned, e.g. with show on select. And it fails
>> altogether, if more than two inputs are involved or if the desired
>> behavior is more complex. Generally any behavior involving two or more
>> inputs should not be handled by one of the affected inputs, but by a
>> dedicated controlling entity that exists once for every form. In fact,
>> in many cases this would even be beneficial where only one input is
>> involved, as it would enable one behavior for multiple input types
>> without having to duplicate code.
>> Semantic Forms Rules would be an extension to MediaWiki building on
>> the Semantic MediaWiki and Semantic Forms extensions. It would allow a
>> much more dynamic behavior of Semantic Forms than currently possible.
>> The idea is to define rules consisting of triggers, conditions and
>> actions. The conditions are evaluated when certain triggers are
>> detected. Depending on the result the associated actions would be
>> performed. Individual rules could be kept very simple, but the result
>> of the evaluation of a rule would be stored and could later be
>> referenced in other rules. This way rules could be chained and more
>> complex rules could be constructed from simple ones.
>> You can find the whole idea on
>> What do you think? Would this be useful enough to have someone spend
>> three month of work on it? If so, should it be done as proposed? What
>> should be changed?
>> Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> Semediawiki-devel mailing list
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> Semediawiki-user mailing list
WikiWorks · MediaWiki Consulting · http://wikiworks.com