From: Yaron K. <ya...@wi...> - 2012-02-06 22:56:33
|
Hi everyone, Version 2.4 of Semantic Forms has been released. As you can guess from the number, this is a fairly major new release. Changes and additions in this version include: - Support was removed for versions of MediaWiki earlier than 1.16. - When you preview a form-definition page, now the actual form is also shown in the preview, in addition to the little bit of text that was already shown by default. This was a feature that was asked about often before, that I think will make form editing a lot easier. Thanks to Solitarius for the patch. - A new parameter was added for the {{{field}}} tag - "values dependent on". This is another often-requested feature - it lets you have the suggested autocompletion values for one field be dependent on the current value for another field. An obvious usage of it is to have the autocomplete values for a city be based on the current value for a country: let's say your form populates the template "Person", which has fields "Country" and "City". If you add the parameter "|values dependent on=Person[Country]" to the tag "{{{field|City}}}", then if a user set the value of the country field to, say, "Mexico", the city field will only autocomplete on values for the city that have been previously set for pages with country "Mexico". (Hopefully that made sense.) - The "query string" parameter for the #forminput, #formlink and #autoedit parser functions can now all be bypassed - for each of those functions, you can take all the values that would be part of "query string", and make them all individual parameters - like "{{#forminput:form=Project|Project[Status]=Started}}". I'm curious to see whether this new syntax option gets used. Thanks to Stephan Gambke for this feature. - A new parameter, "depth", was added to the "category" and "categories" input types. This parameter matches one that already exists in CategoryTree - it sets the initial number of category levels that are shown. - The autocompletion API (done through the MediaWiki API action "sfautocomplete") was modified - instead of the parameters "relation=" and "attribute=", it now just uses "property=". (This is a pretty long-overdue change.) - The Javascript for the "combobox" input type was fixed to work with MediaWiki 1.19. - The SF code was using a PHP function called get_called_class(), which gave errors with PHP 5.2 because it didn't exist yet in 5.2. This has been fixed - thanks to Stephan for the fix. - Form caching was fixed to work with the memcached application - thanks also to Stephan for that fix. - Handling of "redlink=1" was added. In MediaWiki, red links always show up with a "redlink=1" in the query string - this tells the wiki to bring the user to the actual page, if it was created between the time the red link was generated and the time the user clicks on it. Red links generated by Semantic Forms, that point to forms, now use the same mechanism. - There was a fix for the display of red links when $sfgRedLinksCheckOnlyLocalProps is set to true, for SMW 1.7. - There were various other bug fixes, as well as some refactoring of the code. For more information, and to download the extension, see here: http://www.mediawiki.org/wiki/Extension:Semantic_Forms -Yaron |
From: Yaron K. <ya...@wi...> - 2012-02-07 01:54:22
|
Hi, I forgot to mention one more fix in this version: handling of the global variable $sfgAutocompleteOnAllChars was added for both autocompletion on concepts and remote autocompletion, thanks to a patch from Ilmārs Poikāns. -Yaron On Mon, Feb 6, 2012 at 5:56 PM, Yaron Koren <ya...@wi...> wrote: > Hi everyone, > > Version 2.4 of Semantic Forms has been released. As you can guess from the > number, this is a fairly major new release. Changes and additions in this > version include: > > - Support was removed for versions of MediaWiki earlier than 1.16. > > - When you preview a form-definition page, now the actual form is also shown > in the preview, in addition to the little bit of text that was already shown > by default. This was a feature that was asked about often before, that I > think will make form editing a lot easier. Thanks to Solitarius for the > patch. > > - A new parameter was added for the {{{field}}} tag - "values dependent on". > This is another often-requested feature - it lets you have the suggested > autocompletion values for one field be dependent on the current value for > another field. An obvious usage of it is to have the autocomplete values for > a city be based on the current value for a country: let's say your form > populates the template "Person", which has fields "Country" and "City". If > you add the parameter "|values dependent on=Person[Country]" to the tag > "{{{field|City}}}", then if a user set the value of the country field to, > say, "Mexico", the city field will only autocomplete on values for the city > that have been previously set for pages with country "Mexico". (Hopefully > that made sense.) > > - The "query string" parameter for the #forminput, #formlink and #autoedit > parser functions can now all be bypassed - for each of those functions, you > can take all the values that would be part of "query string", and make them > all individual parameters - like > "{{#forminput:form=Project|Project[Status]=Started}}". I'm curious to see > whether this new syntax option gets used. Thanks to Stephan Gambke for this > feature. > > - A new parameter, "depth", was added to the "category" and "categories" > input types. This parameter matches one that already exists in CategoryTree > - it sets the initial number of category levels that are shown. > > - The autocompletion API (done through the MediaWiki API action > "sfautocomplete") was modified - instead of the parameters "relation=" and > "attribute=", it now just uses "property=". (This is a pretty long-overdue > change.) > > - The Javascript for the "combobox" input type was fixed to work with > MediaWiki 1.19. > > - The SF code was using a PHP function called get_called_class(), which gave > errors with PHP 5.2 because it didn't exist yet in 5.2. This has been fixed > - thanks to Stephan for the fix. > > - Form caching was fixed to work with the memcached application - thanks > also to Stephan for that fix. > > - Handling of "redlink=1" was added. In MediaWiki, red links always show up > with a "redlink=1" in the query string - this tells the wiki to bring the > user to the actual page, if it was created between the time the red link was > generated and the time the user clicks on it. Red links generated by > Semantic Forms, that point to forms, now use the same mechanism. > > - There was a fix for the display of red links when > $sfgRedLinksCheckOnlyLocalProps is set to true, for SMW 1.7. > > - There were various other bug fixes, as well as some refactoring of the > code. > > For more information, and to download the extension, see here: > http://www.mediawiki.org/wiki/Extension:Semantic_Forms > > -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Van de B. <van...@gm...> - 2012-02-09 20:07:46
|
It seems you forgot to create tag in svn... On Mon, 2012-02-06 at 17:56 -0500, Yaron Koren wrote: > Hi everyone, > > Version 2.4 of Semantic Forms has been released. As you can guess from the > number, this is a fairly major new release. Changes and additions in this > version include: > > - Support was removed for versions of MediaWiki earlier than 1.16. > > - When you preview a form-definition page, now the actual form is also > shown in the preview, in addition to the little bit of text that was > already shown by default. This was a feature that was asked about often > before, that I think will make form editing a lot easier. Thanks to > Solitarius for the patch. > > - A new parameter was added for the {{{field}}} tag - "values dependent > on". This is another often-requested feature - it lets you have the > suggested autocompletion values for one field be dependent on the current > value for another field. An obvious usage of it is to have the autocomplete > values for a city be based on the current value for a country: let's say > your form populates the template "Person", which has fields "Country" and > "City". If you add the parameter "|values dependent on=Person[Country]" to > the tag "{{{field|City}}}", then if a user set the value of the country > field to, say, "Mexico", the city field will only autocomplete on values > for the city that have been previously set for pages with country "Mexico". > (Hopefully that made sense.) > > - The "query string" parameter for the #forminput, #formlink and #autoedit > parser functions can now all be bypassed - for each of those functions, you > can take all the values that would be part of "query string", and make them > all individual parameters - like > "{{#forminput:form=Project|Project[Status]=Started}}". I'm curious to see > whether this new syntax option gets used. Thanks to Stephan Gambke for this > feature. > > - A new parameter, "depth", was added to the "category" and "categories" > input types. This parameter matches one that already exists in CategoryTree > - it sets the initial number of category levels that are shown. > > - The autocompletion API (done through the MediaWiki API action > "sfautocomplete") was modified - instead of the parameters "relation=" and > "attribute=", it now just uses "property=". (This is a pretty long-overdue > change.) > > - The Javascript for the "combobox" input type was fixed to work with > MediaWiki 1.19. > > - The SF code was using a PHP function called get_called_class(), which > gave errors with PHP 5.2 because it didn't exist yet in 5.2. This has been > fixed - thanks to Stephan for the fix. > > - Form caching was fixed to work with the memcached application - thanks > also to Stephan for that fix. > > - Handling of "redlink=1" was added. In MediaWiki, red links always show up > with a "redlink=1" in the query string - this tells the wiki to bring the > user to the actual page, if it was created between the time the red link > was generated and the time the user clicks on it. Red links generated by > Semantic Forms, that point to forms, now use the same mechanism. > > - There was a fix for the display of red links when > $sfgRedLinksCheckOnlyLocalProps is set to true, for SMW 1.7. > > - There were various other bug fixes, as well as some refactoring of the > code. > > For more information, and to download the extension, see here: > http://www.mediawiki.org/wiki/Extension:Semantic_Forms > > -Yaron > ------------------------------------------------------------------------------ > 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 |
From: Yaron K. <ya...@wi...> - 2012-02-09 20:19:52
|
Hi Van, Well, I didn't forget per se - I just didn't do it yet. I just created a tag now. -Yaron On Thu, Feb 9, 2012 at 3:07 PM, Van de Bugger <van...@gm...>wrote: > It seems you forgot to create tag in svn... > > On Mon, 2012-02-06 at 17:56 -0500, Yaron Koren wrote: > > Hi everyone, > > > > Version 2.4 of Semantic Forms has been released. As you can guess from > the > > number, this is a fairly major new release. Changes and additions in this > > version include: > > > > - Support was removed for versions of MediaWiki earlier than 1.16. > > > > - When you preview a form-definition page, now the actual form is also > > shown in the preview, in addition to the little bit of text that was > > already shown by default. This was a feature that was asked about often > > before, that I think will make form editing a lot easier. Thanks to > > Solitarius for the patch. > > > > - A new parameter was added for the {{{field}}} tag - "values dependent > > on". This is another often-requested feature - it lets you have the > > suggested autocompletion values for one field be dependent on the current > > value for another field. An obvious usage of it is to have the > autocomplete > > values for a city be based on the current value for a country: let's say > > your form populates the template "Person", which has fields "Country" and > > "City". If you add the parameter "|values dependent on=Person[Country]" > to > > the tag "{{{field|City}}}", then if a user set the value of the country > > field to, say, "Mexico", the city field will only autocomplete on values > > for the city that have been previously set for pages with country > "Mexico". > > (Hopefully that made sense.) > > > > - The "query string" parameter for the #forminput, #formlink and > #autoedit > > parser functions can now all be bypassed - for each of those functions, > you > > can take all the values that would be part of "query string", and make > them > > all individual parameters - like > > "{{#forminput:form=Project|Project[Status]=Started}}". I'm curious to see > > whether this new syntax option gets used. Thanks to Stephan Gambke for > this > > feature. > > > > - A new parameter, "depth", was added to the "category" and "categories" > > input types. This parameter matches one that already exists in > CategoryTree > > - it sets the initial number of category levels that are shown. > > > > - The autocompletion API (done through the MediaWiki API action > > "sfautocomplete") was modified - instead of the parameters "relation=" > and > > "attribute=", it now just uses "property=". (This is a pretty > long-overdue > > change.) > > > > - The Javascript for the "combobox" input type was fixed to work with > > MediaWiki 1.19. > > > > - The SF code was using a PHP function called get_called_class(), which > > gave errors with PHP 5.2 because it didn't exist yet in 5.2. This has > been > > fixed - thanks to Stephan for the fix. > > > > - Form caching was fixed to work with the memcached application - thanks > > also to Stephan for that fix. > > > > - Handling of "redlink=1" was added. In MediaWiki, red links always show > up > > with a "redlink=1" in the query string - this tells the wiki to bring the > > user to the actual page, if it was created between the time the red link > > was generated and the time the user clicks on it. Red links generated by > > Semantic Forms, that point to forms, now use the same mechanism. > > > > - There was a fix for the display of red links when > > $sfgRedLinksCheckOnlyLocalProps is set to true, for SMW 1.7. > > > > - There were various other bug fixes, as well as some refactoring of the > > code. > > > > For more information, and to download the extension, see here: > > http://www.mediawiki.org/wiki/Extension:Semantic_Forms > > > > -Yaron > > > ------------------------------------------------------------------------------ > > 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: Andy L. <An...@sf...> - 2012-04-05 09:57:01
|
Yaron, you mentioned in your Semantic Forms 2.4 announcement that you were curious to see if the new querystring syntax on #formlink etc. would be used, so I thought I'd give some feedback on it. I'm liking it and I've found a good use for it. I have some complex #formlinks and #queryformlinks that need to specify a lot of querystring parameters to pass to the form, and often those parameters are themselves built up from quite complex expressions. So for clarity, I like to put each query string parameter on a separate line in the wiki text. This works great with the new syntax where each query string parameter is a separate argument, since the newlines between parser function parameters get stripped. When I tried to do this with the old "query string=" parameter, my newlines would get included in the constructed query string, which caused unexpected results in some cases. ...Andy Quote: > - The "query string" parameter for the #forminput, #formlink and #autoedit > parser functions can now all be bypassed - for each of those functions, you > can take all the values that would be part of "query string", and make them > all individual parameters - like > "{{#forminput:form=Project|Project[Status]=Started}}". I'm curious to see > whether this new syntax option gets used. Thanks to Stephan Gambke for this > feature. |
From: Yaron K. <ya...@wi...> - 2012-04-05 14:36:42
|
Hi Andy, Okay, cool - thanks for the feedback. -Yaron On Thu, Apr 5, 2012 at 5:36 AM, Andy Lawn <An...@sf...> wrote: > Yaron, you mentioned in your Semantic Forms 2.4 announcement that you were > curious to see if the new querystring syntax on #formlink etc. would be > used, so I thought I'd give some feedback on it. > > I'm liking it and I've found a good use for it. I have some complex > #formlinks and #queryformlinks that need to specify a lot of querystring > parameters to pass to the form, and often those parameters are themselves > built up from quite complex expressions. So for clarity, I like to put > each query string parameter on a separate line in the wiki text. This > works great with the new syntax where each query string parameter is a > separate argument, since the newlines between parser function parameters > get stripped. When I tried to do this with the old "query string=" > parameter, my newlines would get included in the constructed query string, > which caused unexpected results in some cases. > > ...Andy > > > Quote: > > - The "query string" parameter for the #forminput, #formlink and > #autoedit > > parser functions can now all be bypassed - for each of those functions, > you > > can take all the values that would be part of "query string", and make > them > > all individual parameters - like > > "{{#forminput:form=Project|Project[Status]=Started}}". I'm curious to see > > whether this new syntax option gets used. Thanks to Stephan Gambke for > this > > feature. > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |