Extension talk:Page Forms

Forms in "values="
I try to get a selection in a dropbox, build by #ask and set by template.

Working with a template works for me with "default= ", before I found the option "now".

So I define "values= ", but even $argvalue is set and passed the recursive-parser (as I testet), I still get the string "  " in my selection.

Any ideas? --Letofred (talk) 10:56, 30 January 2013 (UTC)


 * That should work, I thought... what version of SF are you using? Yaron Koren (talk) 14:17, 30 January 2013 (UTC)


 * (Version 2.5.1) - I don't understand, why it's not working - as far as I can see, it should. --Letofred (talk) 15:26, 30 January 2013 (UTC)


 * If I place my " " anywhere else within the  ...  the template get rendered the right way. Even If I replace the #ask with a constant string like "1, 2, 3, 4" it shows the "  " in my selection.


 * I have no more ideas. --Letofred (talk) 16:00, 30 January 2013 (UTC)


 * Ah, now I remember - the "values=" parameter still doesn't parse its value (though it probably should), though there's a new parameter in version 2.5.1, "values from query=", to which you can add the "filter" part of an #ask query - i.e., something like " First name::John ". I don't know why it's not listed in the documentation yet. Anyway, you should try that. Yaron Koren (talk) 16:18, 30 January 2013 (UTC)


 * Thanks so far. I tryed it and seems to work the way you told. But I have to #ask for a property of an Internal Objekt. To send parameters to the query seems not to work. (tryed: Object::+|? MyProperty ) - any ideas? --47.64.101.221 18:10, 30 January 2013 (UTC)


 * Oh, I see. That might not be possible, unfortunately. But can't you just do "values from property=MyProperty"? Yaron Koren (talk) 19:29, 30 January 2013 (UTC)

"embed in field" for Internal Objects
As far as I see, Internal Objects can not embedded, cause you have to name the field. What for? The fields are also marked by "holds template". Therefor it could be possible to embed a complete Internal Object. Am I right?

--Letofred (talk) 10:56, 30 January 2013 (UTC)


 * Sorry, I don't understand the question. If by "embedded", you mean having multiple template calls in another template call, then... I actually don't see the connection to internal objects. Those go into templates; they're not a part of forms. Yaron Koren (talk) 14:20, 30 January 2013 (UTC)


 * You're right! As far as I understand, the great advantage of the embed-in-field is to store a multible property in a normal form. It just would be quite nice to enbed an Internal Object, which is defined with a "multible" Template, into an other form-template.


 * For example you could add a Internal Object like with the propertys LASTNAME, NICKNAME, BIRTHDATE (or something like that) in just one "normal" form-template for a project with more than one PERSON.


 * You may realise this by different normal form-templates in combination with a multi-template, but maybe this would be a quite nice idea for a futur version.


 * Did I explain it? Did I get the meaning of the embend-in-field? --Letofred (talk) 15:47, 30 January 2013 (UTC)


 * PS: Thank you for your fast reply ;-)


 * You can already do that - just put the #set_internal call in a template, and then, in the form definition, embed that template in another template. Yaron Koren (talk) 16:19, 30 January 2013 (UTC)

Make restricted fields only editable by sysop
Hey, I was wondering if there was a way to make the restricted fields in a form only editable by sysops, and not for regular logged on users. Right now it only removes editing for Anonymous users. Thanks Oh, and just curious if there was an ETA of the new semantic forms version?


 * The restricted parameter by default limits to sysop. If regular users are able to edit restricted fields, then they probably have the editrestrictedfields right (can verify in Special:ListGroupRights). Kodene (talk) 22:10, 3 January 2013 (UTC)


 * There's no ETA on version 2.5.2 of SF, by the way, but hopefully in the next month or two. Yaron Koren (talk) 23:23, 3 January 2013 (UTC)

Different values for "value" and "label" in tags?
Hi Yaron, is there any way to have a listbox get generated with different values for the "value" and "label" attributes of an tag? For example, in a bug tracking application that automatically generates page titles such as: BUG-0001, BUG-0002, etc. Each page has a "short description" property and a list of "related bugs" which point back to the bug page titles. The select list right now can easily be created to render with the page titles like this:

BUG-0001 BUG-0002 BUG-0003 However to the user seeing "BUG-0001" in the list isn't really helpful - it would be great if we could display the short description in the label as well, but keep the value strictly to the page title, like so:

BUG-0001: NullPointerException when entering foo BUG-0002: OutOfMemoryError when bar BUG-0003: DivideByZeroError when bazz

Is this possible? If not I think this could be a really useful feature, perhaps by making use of a supplied template to generate the label? Arcarlucci (talk) 16:54, 4 January 2013 (UTC)


 * This is already possible, using a hack - see here. Hopefully there will be a less hack-ish way to do this in the future - ideally the aliases will be defined in the property page itself, so that the right value can be displayed when the regular page is viewed as well. Yaron Koren (talk) 19:46, 4 January 2013 (UTC)


 * Thanks Yaron! I took your example a step further and made a JSON web service call to the Ask API to obtain the description property of all the pages, and dynamically update each option. Arcarlucci (talk) 17:01, 7 January 2013 (UTC)

Confused about "values dependent on"
Hi Yaron. I think I'm confusing myself on how to use "values dependent on". I haven't been able to get it to work. As a test to try it out, I've done the following:

Property:CPUMake Has type::String Allows value::Intel Allows value::AMD

Property:CPUModel Has type::String

Template:CPU CPUMake:: CPUModel::

Form:CPU

TestPage CPUMake::Intel CPUModel::i3 CPUModel::i5 CPUModel::i7

I've even created pages with only a single CPUModel defined, but no matter what I do the cpumodel field never shows any values regardless of what I select in cpumake. Ultimately, I'm trying to get a 3 tier selection (where C "depends on" B "depends on" A) with finite values (users can't add new ones). I think I've confused myself on how this is supposed to work. Any insights? Kodene (talk) 17:47, 6 January 2013 (UTC)


 * I don't know - that seems like it should work. It could be that "values dependent on" only works if both fields are an autocomplete or combobox, as opposed to (I'm guessing) a dropdown for the first field in your case; I can't remember now. Yaron Koren (talk) 21:09, 6 January 2013 (UTC)


 * I've tried combox for the first field as well, still no dice. Odd thing is that on a whim I copied Template:CPU to Template:CPU2 and updated the cpumodel to point to CPU2[cpumake]. After that I got values appearing in the cpumodel field, but it shows all values set everywhere and doesn't limit based on the selection of cpumake. Guess I'll start going through the source and see if I can get a feel for what it's doing behind the scenes. Thanks for the quick reply. Kodene (talk) 05:30, 7 January 2013 (UTC)

SF 2.5.1 incompatibility with Bitnami Mediawiki 1.20.2 Ubuntu VMWare stack?
Hi,

Previously we were using SF 2.5.1 with a Bitnami MW 1.20.0 installation and everything seems to work.

Recently we migrated to a Bitnami MW 1.20.2 Ubuntu VMWare stack and are running SF 2.5.1 on it. Autocompletion on dropdowns now show for example 10+ instances of several previously entered property. For example, for a state property, we would see MA (previously entered on about 10 different pages) 10 times in the dropdown. Perhaps a problem with deduplication of previously entered values for the property?

A second problem relates to values depend on. On 1.20.0, things were working smoothly. We migrated over the exact template and forms from the 1.20.0 system to the 1.20.2 system and now it is broken as well. The values depend on 2nd field now show all possible values for the property to be triggered by a specific value in the first field. It worked fine in 1.20.0.

We tried reverting back to SF 2.4.2 on the new MW 1.20.2 system w/o any improvement. We also looked at the change log going from MW 1.20.0 to 1.20.2, thinking that perhaps one of the bug fixes affected SF but am unsure what to do. We would like to maintain the new 1.20.2 build and was wondering about potential solutions. Perhaps an alpha or beta version of SF that would be more compatible with MW 1.20.2?

Thanks,

Long


 * That's very strange. Was the only thing that changed the MediaWiki code, that went from version 1.20 to 1.20.2, or did the database change as well, and/or the code for other extensions? And what SMW version are you using? Yaron Koren (talk) 14:40, 10 January 2013 (UTC)


 * The first was a Bitnami MW 1.20.0 stack install onto a Ubuntu system running SMW 1.8 beta2. The second is a fresh Bitnami Unbuntu VMWare running MW 1.20.2 and SMW 1.8 final release.  The two systems were independently setup except for a full copy over of the extensions folder and LocalSettings.php.  Database updates were performed for extensions that require it (SMW, AbuseFilter, AntiSpoof, etc.).  Could the difference in SMW cause this?  -Long- 16:08, 10 January 2013 (UTC)


 * Yes, the upgrade of SMW seems like the much more likely culprit. In SMW 1.8, the entire database structure changed, along with a lot of the code. Not that that should have caused SF to fail, though. Just to clarify, does everything else with SMW seem to be working fine, other than forms? Yaron Koren (talk) 19:00, 10 January 2013 (UTC)


 * Even with SMW 1.8 beta2 vs. 1.8 final? We assumed it would not be a huge difference.  Everything else seems to work fine with regard to SMW, including our heavy usage of subobjects.  We modified subobjects to be similar to SIO in terms of syntax.  We are puzzled why a pipe was chosen as a delimiter for subobjects compared to the the better choice of commas which is used in SIO.  Essentially subobjects behave similarly to SIO in our system.


 * Is there a alpha or beta version of SF that is more compatible with SMW 1.8 final?


 * -Long- 19:14, 10 January 2013 (UTC)


 * Well, I think the big difference between those versions is that in the "final" 1.8, SQLStore3 (the new database structure) became the default setting - that's why you had to update the database (I think). This isn't a public wiki by any chance, is it? As for subobjects and SIO - this isn't really the place to discuss it. :) Yaron Koren (talk) 20:53, 10 January 2013 (UTC)


 * Any easy workaround for that? We mostly care about correct unique presentation of autocompletion elements, values depend on, and autoediting functions in SF. -Long- 21:26, 10 January 2013 (UTC)

Well, it's hard for me to diagnose a fix if I can't see the problem, unfortunately. I'm guessing this isn't a public wiki, then. Is there any way I can get access to it? Yaron Koren (talk) 17:06, 11 January 2013 (UTC)


 * So I changed the SMW backend to SMW_SQLStore2 using SMW_setup.php on a clone of the VMware. SF appears to work.  Now I need to decide whether to run in SMW_SQLStore2 vs. SMW_SQLStore3.  When will the next version (I am interested in even alpha or beta) of SF be out that would be compatible with SMW_SQLStore3?  If just 1-2 months we may bear with the issues we have now.  If 6 months or so, we may go with SMW_SQLStore2 to get full functionality.  Thanks for all your help.  Longphile (talk) 07:00, 15 January 2013 (UTC)


 * Hi - well, SF is currently mostly compatible with SQLStore3 - the only thing that doesn't work, as far as I know, is remote autocompletion. On the other hand, these issues of yours do sound like problems in SF, assuming that everything else is working fine for you with SQLStore3. I can't really guarantee a date by which any particular bug will be solved, but getting SF to work fully with SQLStore3 is definitely a priority for me. Yaron Koren (talk) 22:51, 15 January 2013 (UTC)


 * SQLStore3 is working for us except for this bug: .  SF2.5.1 for us is not fully functional with SQLStore3.  Autocomplete pulls in all instances for certain properties and does not deduplicate into a unique list.  In addition, radiobuttons are presented with 10+ copies of a particular choice even though there are only two unique choices.  Value depends does not work either.  We will eagerly wait for the next SF version then.  Thanks for your help.  Longphile (talk) 09:39, 16 January 2013 (UTC)

Example links are currently not helpful
Most links to examples on discoursedb.org are useless because they block editing from anonymous users.

In mw:Extension:Semantic_Forms/Defining_forms within the show on select text there is a link to http://discoursedb.org/wiki/Special:FormEdit/Source/Some_Source saying "for an example of this feature in use (note what happens when you select different values for the "Publication type" dropdown),". But its not possible to test it, because all input controls are disabled.

Please find some other wikis for linking examples to.--HMichael (talk) 16:35, 10 January 2013 (UTC)


 * Sorry about that - I had changed the settings in Discourse DB in order to test out a feature, but forgotten to change them back. It's fixed now. Yaron Koren (talk) 16:48, 10 January 2013 (UTC)

Text Input Field Size
Hi, I've noticed that text input fields are displaying as different widths in different browsers. This stems from the fact that browsers implement  inconsistently. I'd like to solve this problem by adding a  attribute to the   tag. This overrides the  setting in the browsers I've tested. However I don't know enough to actually make this change in. Would someone be able to point me toward how to add a width argument to the  call that will end up setting   in the html? Or is there a better solution to this problem? Part of the reason the field widths matter so much for me is that I want to have links immediately following fields to collapse them. Here is an example of what I'm working with. Thanks for any help! -- Mw.clearish (talk) 19:12, 16 January 2013 (UTC)


 * You can use the "class=" parameter to set the HTML class, and then add the appropriate CSS for that class elsewhere, like in the page MediaWiki:Common.css. Yaron Koren (talk) 16:30, 17 January 2013 (UTC)


 * Cool, thanks! That's a much cleaner solution than I'd been imagining.  -- Mw.clearish (talk) 16:44, 17 January 2013 (UTC)

independent fancybox upload window
Hi Yaron,

Sorry for the possible off-topic question. Is there any way I can get the fancy box upload windows to work independently of semantic forms? Loaded all semantic forms scripts and css into resource loader (and I mean all), added the classes sfFancyBox and sfUploadable into "upload" link, added this: $wgEditPageFrameOptions = 'SAMEORIGIN'; but still the upload window opens like an "unfancy" normal page Any tip would be greatly appreciated!


 * That seems like it should work... I would add "&debug=true" to the URL, and look at the page with Firebug or Chrome, to see if any errors appear in the Javascript console. Yaron Koren (talk) 01:26, 20 January 2013 (UTC)
 * Finally got it to work (was totally my fault - didn't included all js scripts) Thanks so much Yaron!

Duplicate values in checkboxes when values are from a property
After upgrading to SMW 1.8 and to SQLStore 3, checkboxes in forms are displaying duplicate of values WHEN their values are from a property.

You can see the problem here

Any idea ?

Thanks

Nicolas NALLET (talk) 20:39, 19 January 2013 (UTC)


 * This sounds like the same bug that Longphile was describing, above - I guess this will need fixing in SF. Yaron Koren (talk) 01:27, 20 January 2013 (UTC)


 * Yes this sounds like the same SF bug we saw with SQLStore3. It occurs with checkbox, radiobuttons, or dropdown.  Longphile (talk) 21:56, 26 January 2013 (UTC)

Major bug in Special:RunQuery Special:Ask
Hi Yaron. I'm using Special:RunQuery to crawl through 7000+ bibliographic records. Recently, having upgraded to SMW 1.8, I noticed that Special:RunQuery is missing a lot of results that should have been there. With some further testing it appears that it's always the last part of the string (still under 255 characters) that is ignored by the query. I can't give you precise figures, but it looks as if only the first 60 characters or so are queried. Note that I'm not sure if this behaviour is a recent issue related to SMW 1.8 or SF 1.5.1 - it's only now that I've become aware of it. User:Cavila MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.8, SF 1.5.1 (talk) 09:35, 21 January 2013 (UTC)
 * Actually, the same problem occurs with Special:Ask, so at its heart, this bug is a SMW issue (not SF). Cavila MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.8, SF 1.5.1 10:10, 21 January 2013 (UTC)


 * Yes, I think in SQLStore3 properties of type "Text" can only be queried on their first 60 characters, but - is that worse behavior than what was there before? I thought that in previous versions, you couldn't query on "Text" properties at all - only display them. (And yes, this is not an SF issue.) Yaron Koren (talk) 13:57, 21 January 2013 (UTC)


 * Actually, it happens with properties of type "String" and the first characters that are queried may be even fewer than 60. But yes, it's SMW - the bug has been reported to Bugzilla. Cavila MW 1.19.2, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.1 08:39, 22 January 2013 (UTC)