To clarify, I don't believe I ever said that creating a dropdown list of elements in a category was an SMW issue (which wouldn't make any sense); just that I didn't think it was a worthwhile addition to Semantic Forms. I think Javascript-enabled comboboxes, which are coming (hopefully) soon to Semantic Forms, are the better solution.


On 8/27/07, S Page <> wrote:
Eepē wrote:
> I need a way to automatically pull in a list of articles and/or subcategories in a category for use as a select/drop-/pull-down
> listbox for use in a form. I tried to get Semantic Forms to do this but Yaron insists it's an SMW issue,

I insist it's a Semantic Forms issue :-)

> so I need this
> functionality in SMW then, I guess. ...
> I just need to populate select lists automatically without having to mindlessly enter in everything manually
> every time a category gets a new article/subcat.
> As far as I can tell, only the SMW enumeration type is capable of doing this,

As I understand, Semantic Forms can determine that a template field is
Type:Enumeration , and then displays its allowed values in a listbox.

It would sure be nice if you could point an entry form at part of a
wiki's category hierarchy and say "give me a tree of checkboxes for
category "Effects" and its subcategories", or "give me checkboxes for
every page in category "Effects" with the property [[Covers
topic:=videogames]]"  That seems a feature of a form generator for
MediaWiki, not SMW.

> but requires manually entering in "[[allows  value:=value]]" for every value
> ... Anyway, if I
> can at least get something to pull the articles from a category and add the "[[allows value:="value"]]," part around it that would

You can run a scratch inline query that uses the sep parameter to output
wiki markup around results, and then copy the query results into a
property page.  See
   <ask sep=" ]] [[allows value:=">[[Category:Effects]]</ask>
will output wiki text listing pages in the main namespace in the Effects

To just show subcategories, add the Category namespace as a wildcard;
you have to put a ':' in front of it to avoid confusion.  E.g.,
   <ask sep=" ]] [[allows value:=">
      [[Category:Effects]] [[:Category:+]]</ask>

(queries like this are briefly up on )

*However*, if your goal is to assign a subcategory, i.e. put
[[Category:Weather effects]] into the page, I have no idea if that will
work in Semantic Forms.  Type:Enumeration is for properties, not
categories.  When parsing a page SMW does not enforce what annotations
make sense, so you can put [[Type:Enumeration]] and [[allows
value:=Realistic fog]] on a category page (see ), but
that doesn't make them meaningful.

> (vs. a more logical list of values like "[[allows value:=value,value1,value2,etc]]").

I liked that syntax originally but you run into the 255 character
maximum string length, and it's harder to enter values like "Mild, with
chance of rain".

> What I want to do, for those who may not know, is to replicate in MediaWiki but have the
> form elements dynamically generated relative to category contents (so I don't have to continually edit the form with new options).

Right.  I think that Semantic Forms generates form elements according to
"What does SMW tell me about the properties in this template".  But
current SMW, like wiki text, is open-ended: users write
[[property:=pretty much anything]].

You can request enhancements to wiki forms editors to get information
from other sources (annotations in the template, category hierarchy,
additional special properties, etc.).

You can also request enhancements to SMW to enforce additional
restrictions on types, properties, and categories.  Generalizing
[[allows value]] to other properties besides enumeration seems doable.
Would this help you?  Enforcing restrictions like "If object A is in
category C then its property P can only take values that are
subcategories D/E/F of C" seems cutting-edge ontology research; maybe
one day SMW will be able to do it, but I foresee it'll be in the form of
complicated sets of special properties.

=S Page