From: Stephan G. <s7...@gm...> - 2012-02-13 12:04:17
|
Hi, 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 http://wiki.foxtrott.de/ideas/index.php?title=Semantic_Forms_Rules 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? Cheers, Stephan |
From: Markus K. <ma...@se...> - 2012-02-13 12:42:58
|
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 [1]. It would be much preferable to have a single scripting language being used for all MW in-page programming tasks. Markus [1] http://www.mediawiki.org/wiki/Lua_scripting On 13/02/12 12:03, Stephan Gambke wrote: > Hi, > > 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 > http://wiki.foxtrott.de/ideas/index.php?title=Semantic_Forms_Rules > > 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? > > Cheers, > Stephan > > ------------------------------------------------------------------------------ > 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! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Yaron K. <ya...@wi...> - 2012-02-13 14:27:21
|
Hi Stephan, 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: https://www.mediawiki.org/wiki/Extension:Page_Schemas 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. -Yaron On Mon, Feb 13, 2012 at 7:42 AM, Markus Krötzsch <ma...@se...> wrote: > 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 [1]. It would be > much preferable to have a single scripting language being used for all > MW in-page programming tasks. > > Markus > > [1] http://www.mediawiki.org/wiki/Lua_scripting > > On 13/02/12 12:03, Stephan Gambke wrote: >> Hi, >> >> 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 >> http://wiki.foxtrott.de/ideas/index.php?title=Semantic_Forms_Rules >> >> 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? >> >> Cheers, >> Stephan >> >> ------------------------------------------------------------------------------ >> 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! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> > > > ------------------------------------------------------------------------------ > 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! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Jeroen De D. <jer...@gm...> - 2012-02-13 15:57:57
|
Hey, > it doesn't seem important enough, in my opinion, to get a slot in the Google Summer of Code I tend to agree here. There are things in greater demand that would be useful to more people that could be done. However, I think this idea should go on the GSoC page regardless. If we get a very capable student for it, and have less success for other ideas, then it might very well be worth the effort. > 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. I'd say that SF can definitely handle the vast majority of use cases already. Most forms are relatively simple, with complex ones being the exception. I think there would be more complex forms if there where more advanced features though, so would not be so quick with saying that there is no demand at all. People are familiar with basic form features from other applications, and will demand these if they don't find them. This does not hold true as much for advanced features, which also typically are needed by more advanced users, who might be more prone to assuming it simply can't be done, would take to much work to implement or simply don't have the time to care about it either way. So I think this feature would find use when published and documented properly. Nevertheless, it seems like the 80% of effort to solve the 20% of remaining (potential) use cases. Having more generic systems is always nice though, so I think SF could benefit from this extension. At least, if this new more generic system was actually used by SF. So I think it's worth looking into either putting this into SF, or moving the existing, more limited, functionality out of it and into this new extension. > LUA +1. Introducing even more special syntax is something I would avoid. Then again, it will be a while before the LUA stuff is done, and will take longer before you can use it in SF (or an extension to it). > One other possibility would be to use the structure provided by the Page Schemas extensions instead Yeah, this seems like a nice pragmatic thing to do for now. The parsing done by the new functionality can be made modular in such a way the XML parser for PS can be replaced by a LUA one if that ends up being desired at some point. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Andy L. <An...@sf...> - 2012-02-13 16:35:18
|
Hi all I'm finding the standard cancel button {{{standard input|cancel}}} is not working on partial forms. I'm linking to the form using: [[Special:FormEdit/Form name/{{PAGENAME}}]] though the equivalent using {{#formlink:}} gives the same behaviour. The example referenced in the Semantic Forms documentation has the same problem: <http://discoursedb.org/wiki/Picture_IDs_are_perfectly_sensible> (Click "Add or change this opinion item's references" and then try clicking cancel.) First possible workaround I tried was using a javascript:history.go(-1) link, but MediaWiki won't allow javascript in articles or templates (rightly so of course). I also tried creating an internal link back to the previous page using {{SUBPAGENAME}} but that magic word seems not to work, presumably because I'm using it from within a special page. Any other ideas for workarounds? ...Andy Lawn |
From: badon <fas...@gm...> - 2012-02-17 07:10:38
|
I have discovered that Special:RunQuery is capable of performing unlimited form decision-making, if submitting partial data in a sequential way is acceptable for traversing the behavior pathways. I like the idea and agree with Stephan, and I also agree with Jeroen that if the features were there, they might get used. However, when prioritizing these kinds of projects, I think it's important for me to point out that it is already possible to do what is being proposed, under limited circumstances with a presently-novel use of Special:RunQuery. As people come to realize the capability of Special:RunQuery, I think it will become less novel, and more routine. If that will eventually become the case, or at least remains an open possibility, it might be worthwhile to consider alternative and more expedient ways of achieving Stephan's goals using Special:RunQuery, especially if it will affect decisions about how best to allocate development resources. -- View this message in context: http://wikimedia.7.n6.nabble.com/Could-we-use-Semantic-Forms-Rules-tp4464785p4478802.html Sent from the Semantic Mediawiki - User mailing list archive at Nabble.com. |
From: Markus K. <ma...@se...> - 2012-02-14 09:00:48
|
On 13/02/12 15:57, Jeroen De Dauw wrote: > Hey, > > > it doesn't seem important enough, in my opinion, to get a slot in the > Google Summer of Code > > I tend to agree here. There are things in greater demand that would be > useful to more people that could be done. However, I think this idea > should go on the GSoC page regardless. If we get a very capable student > for it, and have less success for other ideas, then it might very well > be worth the effort. > +1 The purpose of GSoC is not only to benefit the host project but also to allow fresh developers to pursue some interesting (for them) projects, i.e., to learn something. So from this perspective, I would not stop a good applicant who really wants to do this (or any other sound idea that they really want to do). I am sure that the initial discussion with the mentor can always lead to a project plan that maintains a good balance between being useful and being interesting. Markus |
From: Stephan G. <s7...@gm...> - 2012-02-21 20:13:33
|
>> > it doesn't seem important enough, in my opinion, to get a slot in the >> Google Summer of Code >> >> I tend to agree here. There are things in greater demand that would be >> useful to more people that could be done. However, I think this idea >> should go on the GSoC page regardless. If we get a very capable student >> for it, and have less success for other ideas, then it might very well >> be worth the effort. >> > > +1 > The purpose of GSoC is not only to benefit the host project but also to > allow fresh developers to pursue some interesting (for them) projects, > i.e., to learn something. So from this perspective, I would not stop a > good applicant who really wants to do this (or any other sound idea that > they really want to do). I am sure that the initial discussion with the > mentor can always lead to a project plan that maintains a good balance > between being useful and being interesting. Hi, thanks for your comments. What I will do is, I will add the task to the page with the understanding that other project ideas will have precedence if there are applicants for them. I guess I will also have a closer look on Page Extensions. I'd rather not use Lua for this because 1. this would indeed mean introducing another language for specifying things in forms, 2. MW itself does not support Lua yet and 3. I simply do not have any experience with it. Of course, the whole thing would need to be discussed with the student and the result could well be to go for Lua anyway. Cheers, Stephan |
From: Yaron K. <ya...@wi...> - 2012-02-21 21:07:26
|
Hi, That sounds like a good idea, and that's what I should have said before - sorry about that. After all, ultimately it's up to the students, not me or anyone else, what projects get done. -Yaron On Tue, Feb 21, 2012 at 3:13 PM, Stephan Gambke <s7...@gm...> wrote: > > > >> > it doesn't seem important enough, in my opinion, to get a slot in the > >> Google Summer of Code > >> > >> I tend to agree here. There are things in greater demand that would be > >> useful to more people that could be done. However, I think this idea > >> should go on the GSoC page regardless. If we get a very capable student > >> for it, and have less success for other ideas, then it might very well > >> be worth the effort. > >> > > > > +1 > > The purpose of GSoC is not only to benefit the host project but also to > > allow fresh developers to pursue some interesting (for them) projects, > > i.e., to learn something. So from this perspective, I would not stop a > > good applicant who really wants to do this (or any other sound idea that > > they really want to do). I am sure that the initial discussion with the > > mentor can always lead to a project plan that maintains a good balance > > between being useful and being interesting. > > Hi, > > thanks for your comments. What I will do is, I will add the task to the > page with the understanding that other project ideas will have > precedence if there are applicants for them. > > I guess I will also have a closer look on Page Extensions. I'd rather > not use Lua for this because 1. this would indeed mean introducing > another language for specifying things in forms, 2. MW itself does not > support Lua yet and 3. I simply do not have any experience with it. Of > course, the whole thing would need to be discussed with the student and > the result could well be to go for Lua anyway. > > Cheers, > Stephan > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > 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! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |