Auto-generated form fields & field chooser

[Eep²]

I need form fields (specifically checkboxes and/or select listboxes) to be auto-generated relative to categories (and other ways
like backlinks that use a certain template, like Dynamic Page List can do) for
http://www.tnlc.com/wiki/index.php?title=Special:AddData/Game/test .

Also, can the "chooser" also work for additional fields on the CURRENT template (without having to specify yet another template for
every field)? Since SF doesn't support multiple values in the same field (that will automatically appear concatenated from, say,
multiple checkboxes), I need to be able to add multiple fields of the same name for the user to choose multiple options in an
enumeration type, as in various fields on the aformentioned form . (But even then I'll still have a problem getting multiple
same-name fields crammed together in a, say, comma-separated list for my game feature comparison table...<sigh>)

[Yaron Koren]

For the first issue, I don't understand the request. For the second, unfortunately you're out of luck: it's true that SF doesn't support multiple inputs populating the same field, but MediaWiki itself doesn't support having more than one field with the same name per template; that's because the parser would then be confused about which one gets substituted where.

-Yaron

[Eep²]

... Have you even ever used DPL, Yaron? It can generate lists of things, like articles within categories, articles that link to
other articles, etc. What I need is similar functionality in SF but that allow those lists to be turned into lists of form elements
like checkboxes, for example (and select listboxes, more preferably). So, as you can see from my form, I have a "water"
"atmospheric/environmental" "effects" section with "bubbles", "current", "drops", "ripples", "splash", and "waves" checkboxes.
Instead of having to create these checkboxes manually, I want that checkbox list to be automatically generated relative to the
contents of the, say, "water effects" category (which contains all of those articles). Then, if a new water effect article is
created, the checkbox list will automatically create a new checkbox for that article the next time the form is displayed. Got it?

MediaWiki can most indeed certainly support multiple field types in a template. Look at
http://www.mediawiki.org/wiki/Template:Extension which supports comma-separated extension types, for example. But what I'm asking
for isn't theoretical physics, Yaron. I just need multiple fields (they don't even have to have the same name either) to be combined
and separated by a comma, for example. So, if I have break=tables, break1=doors, and break2=lights, I want them all combined as a
single "break=tables, doors, lights" (with the separator/delimiter configurable--in this case ", ").

From: Yaron Koren
Sent: Thursday, August 16, 2007 7:23 AM

For the first issue, I don't understand the request. For the second, unfortunately you're out of luck: it's true that SF doesn't
support multiple inputs populating the same field, but MediaWiki itself doesn't support having more than one field with the same
name per template; that's because the parser would then be confused about which one gets substituted where.

[Yaron Koren]

I've never used DPL, though I'm aware of the functionality. Now I understand - you're asking about creating form elements dynamically, with some sort of rule. Unfortunately that's not possible, and I don't think adding such functionality would be worth the extra complexity. You'll have to add the form elements manually.

For the second issue, I had misunderstood your question; I thought you were asking about multiple fields in a template with the same name. Yes, obviously comma-separated values are allowed, though your specific example seems odd: if you know that there will be at most three (or however many) "break" fields, why not create a separate text input for each one? Why make the user separate them by commas in one big text input?

-Yaron

[Eep²]

You may want to actually try DPL to see just what SF is missing. SF would be a lot more useful if it had similar functionality that
applied to forms as well. It's unfortunate I can't even get Simple Forms to work, or I'd probably be using that instead, as it seems
to be a more versatile form extension than Semantic Forms...

Regarding multiple fields, that's not what I'm saying... I don't WANT the user to HAVE to separate multiple entries with a
comma--that's where the concatenation comes in--where things are COMBINED.

From: Yaron Koren
Sent: Thursday, August 16, 2007 2:21 PM

I've never used DPL, though I'm aware of the functionality. Now I understand - you're asking about creating form elements
dynamically, with some sort of rule. Unfortunately that's not possible, and I don't think adding such functionality would be worth
the extra complexity. You'll have to add the form elements manually.

For the second issue, I had misunderstood your question; I thought you were asking about multiple fields in a template with the same
name. Yes, obviously comma-separated values are allowed, though your specific example seems odd: if you know that there will be at
most three (or however many) "break" fields, why not create a separate text input for each one? Why make the user separate them by
commas in one big text input?

[JeffreyStuckman]

Well, creating a checkbox or listbox would require the creation of an
attribute to store the data. So, even if Semantic Forms was able to
automatically generate a form element, Semantic MediaWiki still
wouldn't have anywhere to put it.

You know, I wanted to do this in my own wiki, too. I was able to solve
the problem by writing a PHP page that registered a MediaWiki hook (an
article save hook). Whenever a new article is created in the Attribute
namespace with the proper category, it dynamically regenerates the
form with the new attribute. This requires writing a few pages of PHP
code, but no modifications to SemanticForms are required.

[Eep²]

Well, I would need something that would update the form whenever a page is added to a category. Perhaps your PHP code could be
adapted for this, perhaps even as an extension by itself?