Extension talk:Page Forms

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)