Extension talk:SemanticQueryFormTool/Archive

New Storage Engine
Will there be support for the new Storage Engine and will there be a SVN Repository for this Extension? Because then I could use this Extension on WeCoWi. --DaSch 09:54, 8 September 2008 (UTC)
 * Hopefully yes at some stage. I'll try to keep this 'old storage engine compatible' version (with all its limitations) working with upcoming SMW versions but any new SQFT version would long-term anyway only make sense if its working with the new storage engine. Optimale 14:14, 8 September 2008 (UTC)

Dependent Selection
Is there a possibility to make several mselect-boxes dependend on each other? I'm trying to have a search form that incudes (among other options) a search for countries, regions and villages/cities. Now it would make great sense, if one couldn't choose first a land and then a region that's NOT in the land you chose in the first place, and in the next step one shouldn't be able to select a city that isn't in the selected region.

Thats my code so far, it's heavily stripped from your example:

Results: -

(I'm using SMV-properties because I want to have a boolean AND within that search, and afaik that wouldn't be possible with built-in wikipedia categories.) Is there a way to make the mselect boxes dependend somewhat like this: Country A -> Regions in Country A -> Cities/Villages in Region B in Country A

Thx,

Simon -- 12:05, 15 September 2008 (UTC)


 * Sorry for the late reply.


 * Yes you can do something like that with the help of javascript functions which are attached to a field of the form with the 'js=' parameter. I use it in a very similar way like you describe (except in a different context - if a certain chromosome is selected from the 'chromosome' select element the values in another select element for 'bands' change accordingly to allow only those bands to be selected which are located on the selected chromosome(s)). It's however not very elegant as the javascript has to contain hardcoded the information e.g. which country has which regions and which regions has which villages/cities in order to enable the script to disable (gray out) or remove certain elements from the select list resp. add/enable them 'on the fly'. One can do some quite advanced stuff with the right javascript but it's basically not different at all from what one can do to control elements of a normal form in a normal HTML site using javascript.


 * I use the addscript extension to add javascript functions which I store in a file on the server. But in theorie the whole script could be added directly as value to the 'js' parameter. So would might have the extra parameter  which calls the js function select_disable if the country is changed and which than can modify the region select element depending on the country value.


 * Btw to have 'any=(alle)' is not useful as SMW only understands '+' and '?' as wildcard characters for ask queries; this parameter is more useful to switch the display of '+' or '?' OFF e.g. in lists.


 * Optimale 17:01, 24 September 2008 (UTC)

Database error: table .cmw_smw_atts2 doesn't exist
Hi,

after installation, I get the following error:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "SQFTSMW::getSelectResult". MySQL returned error "1146: Table 'XXXX.cmw_smw_atts2' doesn't exist (localhost)". -Bernhard


 * Sorry about that. It was a bug - the database prefix was still hardcoded from the initial test :(
 * It should work now with version 0.1.2 on the ftp site
 * Optimale 22:54, 12 October 2008 (UTC)

Problems with MW1.13.2 and SQFT0.1.3
Hi all!

I don't know what I did, but the newest version of this extension (it's very helpful, many thanks for it!) does not work for me. I have a new installed MW1.13.2 and created two simple pages:
 * Page_one contains: Propertyname::one
 * Page_two contains: Propertyname::two

and a third:
 * Page_three contains:

but the option list of select tag is empty. I set the $wgShowSQLErrors and $wgDebugDumpSql variables to true in LocalSettings.php, but there are no error messages. The select tag appears nice. The page id's are there in prefix_smw_rels2 table. My SMW version is 1.3.

Can anybody help me? Thanks: Pipi69e 13:50, 30 October 2008 (UTC)

PS.: with type=article it works (it finds the correct property-page relations). Pipi69e 14:13, 30 October 2008 (UTC)

Pagename attribute causes MySQL error
Using pagename attribute causes the next error message: A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "SQFTSMW::getSelectResult". MySQL returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 (localhost)".

The form works fine. Pipi69e 15:21, 30 October 2008 (UTC)


 * I think I finded an unnecessary closing bracket ')' on the end of 265. line of SemanticQueryFormTool/includes/SQFT_SQLFunctions.php. Deleting it solves the problem. Pipi69e 19:10, 30 October 2008 (UTC)


 * I just uploaded version 0.1.5 which hopefully resolves all bugs connected with retrieving property values of all types w/out specified namespace and/or pagename
 * Optimale 13:43, 6 November 2008 (UTC)

Update for SMW 1.4?
SQFT is currently (SemanticQueryFormTool_01_5.zip) not compatible with the newest SMW version. Would be cool if you could update it to make it work again :)
 * Version 0.1.6 is the last version compatible with <= SMW 1.3
 * Version 0.1.7 is the first version compatible with >= SMW 1.4
 * Optimale 10:51, 25 November 2008 (UTC)
 * Great, thanks :) --Pnagel 02:52, 26 November 2008 (UTC)

Simple #sask query for property of type Page doesn't work
Until now I always used SQFT's #sask for properties of type String. Now I wanted to use it with a property of type Page (explicitly specified in the Property page), but I only get a dropdown with a + in it, although there are >30 pages using the property. The query I tried was:

What am I doing wrong? --Pnagel 06:34, 9 January 2009 (UTC)
 * Sorry again for the late reply but somewho I don't seem to get the notification emails when this page is modified :(
 * Anyway it was a bug. I forgot in one place to replace the spaces of property names with underscores for the sql query. I corrected that now in version 0.1.9
 * Optimale 12:35, 26 January 2009 (UTC)

Example
This extension looks like it could be very useful. However, I tried to look at the example on malariapedia just now, but the site seems to be down. Do you know when that site might be available again or indeed if there is another place I could see a working example of this extension? Thanks Pnelnik 18:10, 17 February 2009 (UTC)
 * Unfortunately I don't really know of any other wiki where one could see the extension in action but the help.malariapedia.info site is up and should be accessible. It might be slow at times as it is a test site on an old server but the wiki will be moving to a new and hopefully faster hardware soon. So please try again to connect. Optimale 22:10, 17 February 2009 (UTC)
 * Maybe it's a result of the unusual port (14195) the webserver at mbi.molgen.mpg.de is running on - many company's firewalls or proxies will block outgoing traffic to this port. --Patrick Nagel 02:51, 18 February 2009 (UTC)

Thanks for the prompt response. I seem to be able to see the web-site today. Pnelnik 16:24, 18 February 2009 (UTC)

Combine two query conditions?
I'm currently mainly using #sask to generate tables with two columns, one containing property values, the other containing the number of times this value has been used. Now I'm wondering if it would be possible to get such a table that only contains the number of times a value has been used together with another condition, for example only matching pages that are in one specific category. Is it possible? --Patrick Nagel 08:00, 23 February 2009 (UTC)
 * Right now only those criteria can be used which are directly accessible within the SQL queries for the property values. These criteria are pagename and namespace. Using Category restrictions would mean to retrieve each page associated with a property value and do an extra DB search if that page is within a certain category or not. That would take too much time as the SQL queries are already time consuming if the number of properties is very high. So you can only restrict the result to matching pages within a list of pagenames or to pages within a list of namespaces. The other 'filter' action is after the retrieval purely based on the actual property values.
 * Well thinking of it there could be a 'trick' to restrict for Categories but I have so far never tested nor used it - so it might not work in practice:
 * In the 'article' mode a 'normal' #ask: query is used which can include Category: and it returns a list of linked pagenames. Most likely one has to somehow switch the linking off?
 * I'll see if I get it working and let you know. Optimale 13:44, 23 February 2009 (UTC)
 * I just made some modifications and from the next version it will be possible to feed a list pagenames to the pagename= parameter which is generated by a i.e. category specific #sask: type=article query e.g.:
 * but that could of course return a very long list of articles which might not work due to some limitation. But it works in principle. Optimale 16:25, 23 February 2009 (UTC)
 * but that could of course return a very long list of articles which might not work due to some limitation. But it works in principle. Optimale 16:25, 23 February 2009 (UTC)
 * but that could of course return a very long list of articles which might not work due to some limitation. But it works in principle. Optimale 16:25, 23 February 2009 (UTC)

Wanted links ?
Hi

I am using your great extension to display a list of values (keywords) from a property and provide links to pages for these keywords.

It is working fine except for one thing - all links are displayed the same way, whether the page exists or not.

Would you consider making link display aware of 'wanted pages' in a future version to make the display of links more consistent with the rest of the wiki ?

Regards

- Laurent Alquier
 * I assume you mean 'red' links to non-existing pages are blue? I haven't tested that so I have to look into it as I actually thought MW would take care of returning the correct link. Optimale 20:04, 28 March 2009 (UTC)


 * In the next version (0.2.1) links to non-existing wiki pages will show as 'red links'. Of course it makes only sense to add the 'link=' parameter (adding an internal link) if the property values are intended to be page titles, otherwise links will always be red.
 * It checks and tries to link to pages with the name of the property value in the 'Main' namespace. Only if the global variable '$sqftgAllowedNamespaces' is set, it checks through those namespaces first and uses the first namespace in which it finds a page with the name of the property value. If no page in any of those namespaces is found it shows a 'red link' to the page in the 'Main' namespace. Optimale 11:20, 30 March 2009 (UTC)

Only Property Values of Type 'Page' Returned After SMW Rebuild
Hi- I've discovered a very strange bug in SQFT (which is great! I've been using it extensively to enhance SMW.).

I have a large SMW installation. Versions: MW 1.13.3, PHP 5.2.4, mysql 5.0.51, SMW 1.4.2, SimpleForms 0.4.10.1, SQFT 0.2.0 SQFT was installed normally (no caching, no SQFT tables or indexes created).

'#sask' worked just fine when I installed it a month or so ago, and has worked well during that time. I could build unique lists of whatever semantic property in my system... Then, this week, my semantic tables got corrupted, so I used the recommended steps to rebuild everything from scratch using the SMW maintainance scripts:   After doing this, the SMW stuff all worked again just fine, as did many other SMW related extensions(results format most importantly)... but I noticed that #sask stopped working. This hosed a lot of pages. But, #sask did continue to work for Properties whose type was 'Page'? (where before the type of the property did not matter) If I switched some of the properties failing to return value lists from 'number/string/etc' to 'Page' suddenly #sask would work again?! And when switched back to 'number/string/date/etc' nothing would be returned. (note- I did make sure the database updates all succeeded, and touched LocalSettings.php between each change).
 * 1) delete old smw* tables.
 * 2) rebuild smw* tables.
 * 3) refresh smw* data for properties and types only.
 * 4) refresh smw* data for everything else.

Any help would be greatly appreciated. Thanks- User:iamh2o (Mar 28 2009)
 * As far as I know I use only the normal SMW tables to retrieve the data. I use SMW 1.4.2 (actually in Special:Version it says 1.5e-SVN), MW 1.14.0 and SQFT works for me for properties of type String and Number. I'll look into it on Monday. Do you have acces to the MySQL database, so you could enter some test queries directly? Optimale 20:39, 28 March 2009 (UTC)


 * Thanks for the quick reply! Yes, I have admin access on the box this wiki runs on, and would be happy to run test queries.  This is indeed odd: I didn't change SMW code at all, so the tables and data which were rebuilt should be exactly the same as when SQFT was working pre-schema/data refresh(and are as far as #ask query results I've QC'd go the SMW stuff all works fine).
 * I'll check back Monday. User:iamh2o (Mar 28 2009)
 * I sent you an email Optimale 16:39, 30 March 2009 (UTC)


 * The problem is resolved. It was caused by the fact that SQFT only transformed the first letter of a property name in an #ask query to uppercase when the property was of type Page but otherwise used the name as written in the query. As all property names are stored with the first letter in uppercase this caused problems in SQL queries. From SQFT version 0.2.1a all property names are treated like the Page properties and the first letters of property names in #sask queries are now case insensitive. Optimale 09:35, 2 April 2009 (UTC)

Different id and name values
Hi Optimale!

If I add a name parameter to a select element, the value of id has got same value in HTML source. If I add an id, then the name follows it. But if I add an id and a name params together then they won't be different, but the value of name will be ignored and it will be the same as the value of id. How can I add different id and name values to a select?

Thank You for Your extension :) Pipi69e 19:18, 23 May 2009 (UTC)

PS - versions: MW 1.14.0 and SQFT 0.2.4


 * You are welcome. I'm really surprised that it doesn't keep the values of both if both are specified. It defenitly should and if not it is a bug. I'll look into it asap and fix it in the next release. Optimale 22:15, 23 May 2009 (UTC)
 * Yeah it is a bug. 'name' and 'id' are always added. If 'id' is not given, 'id' will equal the value of 'name'. If 'name' is not set 'name' will be the property name if a property is specified otherwise it will be the page title. I'll put up version 0.2.5 on Monday. Optimale 22:34, 23 May 2009 (UTC)
 * Many thanks for Your fast reply and help. I'm trying to use selects of Your extension in forms created by Semantic Forms extension and that's why I need correct id and name values. Pipi69e 08:34, 24 May 2009 (UTC)
 * I never used it myself in SF but select and multi-select form elements were the original purpose I wrote SQFT for. If you have any problems let me know. Btw the name and id values will all be forced to be lowercase (that's because by default it used the property name which usually starts with a capital letter and I thought it's less trouble if the id/name value case is independent how it was defined) so if you refer to those elements e.g. in javascript keep that in mind.
 * This next version will also have a new 'style' parameter which you can use for select elements too to i.e. define the text size if desired (e.g. style=font-size:90%;color:red) Optimale 10:57, 24 May 2009 (UTC)
 * I put now SQFT version 0.2.5 up for download which fixes this bug. Optimale 09:00, 25 May 2009 (UTC)

Call to undefined method SQSimpleForms::updateTemplates
Hi Optimale!

Here are some reflections again. I use both your SQFT and Simple Forms. If I'm writing this:

and the page Something exists, your SQFT says: Warning: in_array [function.in-array]: Wrong datatype for second argument in .../extensions/SemanticQueryFormTool/includes/SQFT_SimpleForms.php on line 506

Fatal error: Call to undefined method SQSimpleForms::updateTemplates in .../extensions/SemanticQueryFormTool/includes/SQFT_SimpleForms.php on line 514 I think, the line 506. of SQFT_SimpleForms.php is really bad, the second argument of in_array function is $wgSimpleFormsAllowRemoteAddr instead of $wgSQSimpleFormsAllowRemoteAddr now. But where is the updateTemplates function of the SQSimpleForms class ;) and why works SQSimpleForms class when I use parser functions of Simple Forms? Many thanks again :) Pipi69e 02:15, 27 May 2009 (UTC)


 * That was an interesting one. Good catch, thanks! I don't want to go too much into details but making a modified extension part of another extension is obviously more complicated than I anticipated. SQFT_SimpleForms is included within the SQFT_Settings file and the constructor function is called each time. It already calls a function to process an existing request using $_REQUEST variables. It didn't distinguish if the in both SimpleForms identical named variables where generated from a normal SimpleForms or a SQFT_SimpleForms form. As SQFT_SimpleForms is a simplified version made to deal only with the type of forms used for SQFT it didn't have all the functions necessary to deal with the request. I'm sure there is a proper way to solve those issues but for now the solution is to download version 0.2.5a of SQFT. It is sufficient to replace the SQFT_SimpleForms.php file in your existing installation and it should work. Optimale 13:52, 27 May 2009 (UTC)

Enter a property in SQFT and find what page it appears on.
I would like to select a value of a property with SQFT and then, on pressing the button, display the names of the pages where that property value exists.

Eg, I have tests displayed by test ID and each test has a name, giving the following table:

Test ID  - Name

T1        -  Roger

T2       -   foo 123

T3        -  Alice

When I Do, I get the list of values. How can I make it show Test ID when I select a value from that list?

-The reason for this is that users must enter test ID as it is a unique value but they cannot be expected to remember it, therefore a quick lookup query where they could find the ID from the name is necessary. Thanks
 * SQFT itself deals in this context only with values of one property at a time but from all pages of a wiki (not taking into account using optional restrictions to one namespace/category/page). To achive what you want you will have to combine SQFT's #sask: queries with a normal #ask: query. The only thing which springs to my mind right now is the use of a form which is what I routinely do for my queries. E.g. something like this (using Ajax to show the results):

The chosen 'Name' value can be found on these pages: NO RESULTS TO DISPLAY YET


 * You can customize the #ask query i.e. choose a different output format if you want
 * Note that 'value = ' needs of course to be written without the space between 'no' and 'wiki' in the real code
 * Optimale 08:02, 1 July 2009 (UTC)

Thankyou very much Optimale for your fast response.

That looks like it should be doing what I want (i.e, the results appearing directly on the page) however I get the following error when i click the 'show results' button. Error: 404 Not Found (There is currently no text in this page. You can search for this page title in other pages, search the related logs, or edit this page.)

I am not sure if this is:

The pages are in the category "Coupon Type" and it is the autogenerated page name that I wish to display as well as the property "Ctdesc" - (description). I wish to search by the property "Ctname". Simply substituting 'Ctname' where you have written 'Name' in the above example gives me a form that looks exactly how I want but the above error. I assume 'namevalue' is a variable and I can leave it.
 * my incorrect substitution of variables into your code;


 * Ajax problem/other config? - I have put '$wgUseAjax = true;' into my localsettings. I have not done any of the optional steps mentioned in the main wiki page for the extension.


 * Problem in above code??

Thanks Again Ben 2-July-09


 * Hmmm looks like an Ajax problem although I have never seen it before.
 * I just tried the exact code syntax on my wiki, just replacing 'Name' with one of my property names and it works as expected.
 * $wgUseAjax = true; should be sufficient.
 * What MW, SMW, SQFT version are you using?
 * Do normal #ask: and #sask queries work? I assume you get the pull-down list with the Ctname property values?
 * Might have somthing to do with SF although the error indicates that it wants to open a page which looks more like an Ajax problem.
 * If you add the above code on a normal test page and replace 'Name' with 'Ctname', does it work without SF involved?
 * Optimale 11:47, 2 July 2009 (UTC)

I am using: (from Special:Version) MediaWiki 1.15.0 PHP 5.2.6-3ubuntu4.1 (apache2handler) MySQL 5.0.75-0ubuntu10.2

Data Transfer (Version 0.3.1) Semantic Drilldown (Version 0.5.7) Semantic Forms (Version 1.7.1) Header Tabs (Version 0.6.5) Semantic MediaWiki (Version 1.4.2) SemanticQueryFormTool (Version 0.2.5a) I have discovered a problem with normal #sask with the following (on test page, nothing else on that page):

I get the drop down, but when I click the button, get the same error as in previous post.

When I use: I just get the select drop-down and no button. I assume that is normal.

Normal #ask queries such as:

works fine.

Could it be a problem with MW 1.15??


 * I didn't have the time yet to install and test MW 1.15 but it all sounds like some Ajax issue with MW 1.15. I'll see if I can install 1.15 and test it out.
 * With normal #sask queries you don't get any buttons, that's ok (only with return=form);
 * Optimale 08:12, 3 July 2009 (UTC)


 * I now installed and tested MW 1.15 and it is till working on my test wiki. something like works as expected.
 * I can't get the Ajax examples NOT to work, so I guess there is something different with your 'Ajax' compared to mine but I have no idea what it could be.
 * Do you use Ajax on the wiki in any other context? Maybe using the original SimpleForms extension?
 * When it gives the Error: 404 Not Found (There is currently no text in this page. You can search for this page title in other pages, search the related logs, or edit this page.) what page name does it try to open or create when you try to edit the page?
 * Optimale 10:46, 3 July 2009 (UTC)

I am not using any other AJAX. The links in the error message point to

/index.php/Special:Search/UNTITLED

Ben 02:20, 6 July 2009 (UTC)

Hey, I possibly found a bug. I created a page called "UNTITLED" and now it seems to be working a bit better.

with return=form, I push the button and it returns "0" pages with that property value but the correct answer is "1". For another property, it returns "3" when the correct answer should be "1".

With the code that you gave me above, i now get the following error:

'''warning.png "" cannot be used as a page name in this wiki. Some use of " " in your query was not closed by a matching "".'''

The problem is with the substitution of #sqvar. When I directly specify a value such as:

value = }}

it works perfectly. I think I am getting close now, thanks

203.5.217.3 07:41, 6 July 2009 (UTC)

Actually, Firefox 3.5 and chrome 2 work. Just Not IE7.

203.5.217.3 07:48, 6 July 2009 (UTC)


 * I have IE6 here and yes I get the same errors. If I don't use Ajax it works fine (you can try it if you replace '{{#sqinput: type=ajax | ...' with '{{#sqinput: type=submit | ...') but if Ajax is used then Name::{{ ends up as Name::]]
 * You can see it if you add to the ' {{#ask: ' query the parameter 'format=debug'
 * I never use IE so I didn't experience that problem before. I'll see what I can find out.
 * So using Firefox or Chrom everything works otherwise for you now?
 * Optimale 09:24, 6 July 2009 (UTC)


 * I found the problem!
 * In contrast to the other browsers IE doesn't understand options[selectedIndex].value if there isn't a value explicitly defined and for IE one has to use options[selectedIndex].firstChild.nodeValue. So it never assigned the selected value from the drop-down menu.
 * I have put SemanticQueryFormTool_02_5b.zip up for download which fixes that problem.
 * The above query form as well as #sask: with 'return=form' works now for me with IE6 as well as Firefox.
 * Thanks for finding the bug and helping to solve it!
 * Optimale 10:24, 6 July 2009 (UTC)

The fifth installation step
What does the fifth step mean? create index p_s_val on $wgDBprefix_smw_atts2(p_id, s_id, value_xsd); create index p_o_id on $wgDBprefix_smw_rels2(p_id, o_id); what to do?


 * Hi, this is a step you have to perform in you MySQL database (see here for reference). Just access your database, most probably by using the application phpMyAdmin, select your database on the left side and klick on the tab SQL at the top of the page. Now you get a blanc field in which instructions are inserted. There you insert create index p_s_val on $wgDBprefix_smw_atts2(p_id, s_id, value_xsd); and press enter after exchanging „$wgDBprefix_“ by the prefix you used for the tables of your MediaWiki installation. E.g. if you prefix was mw_ you instert create index p_s_val on mw_smw_atts2(p_id, s_id, value_xsd);, if you somehow did not use a prefix for some bad reason you enter create index p_s_val on smw_atts2(p_id, s_id, value_xsd); etc. mw_smw_atts2 or smw_atts2 should be the name of one of the tables displayed on the left side. You do the same thing with the second instruction. Voilà! Cheers --kgh 20:48, 28 April 2010 (UTC)