https://bugzilla.wikimedia.org/show_bug.cgi?id=28260
--- Comment #2 from John McClure <[email protected]> 2011-03-27 21:06:53 UTC --- Sure. First of all, it's fair to say that ontologies can easily have hundreds if not thousands of categories. As you well know the OWL world maps its classes to wiki categories, and that larger ontologies can have thousands of classes both explicitly and implicitly declared. And also that many strongly argue the need to declare only classes that have at least one unique existential property or constraint. So the SF approach is that every class has its own form, and every form has its own form-template (so that subclasses can inherit the same form-template which defines the properties of that class perforce common to its subclasses) which all suggests that SF envisions a hierarchy of form-templates coinciding fairly exactly to the class hierarchy buried & expressed within Category: entries. The SF approach can lead to systems more difficult to maintain. For instance, let us propose that a Persons category has Adults and Minors category, the latter has Boys & Girls categories. So I want a form for minors different than for adults, and the only difference between the boys & girls forms is one says Boy's Name & the other says Girl's Name. How do I do that simple thing? Option 1. {{template:minor form|Boys}} is called by form:Boy and {{template:minor form|Girl}} is called by form:Girl. Option 2. embed either Boy or Girl into the name of the page so that it can be queried in Form:Minor. eg {{#ifexpr: {{#titleparts:{{PAGENAME}}|...}}|Boys Name|Girls Name}}. This method means there is no need for either a Form:Boy and Form:Girl - hooray! Option 3. Is there one? How about one form:Minor with no templates at all: {{#ifexp: {{#formvar:Minor|Category}}=Boy OR {{#show:{{PAGENAME}}|?Category}}=Boy |Boys Name|Girls Name }} Hmm, why does SF require that my form need query the smw store to retrieve a value simply stored by template:Minor? Especially when it's right there, already parsed, and placed into a field on the form by SF? In other words, {{#formvar:}} retrieves the value of a variable for a template as it would be 'saved' at that moment by the SF processor, which would HAPPEN to correlate to the value that is used by the template itself. ----- Ultimately there is a direction for this. Currently SF is a stateless processor - it even requires special forethought to tell when the form is being applied to a new page vs an existing page! {{#formvar}} blurs the line between when user-defined processng occurs; now such is only when the form is SAVED, period. With {{#formvar}} one can then define STEPS within a form, each corresponding to a NEXT STEP button. The {{formvar}} parser function is invoked by a form step, storing intermediate data itself, eg {{for template|Minor}} ... {{end template}} {{for step|x}} {{Minor |category={{#formvar:Minor|category}} }} {{end step|x}} IOW, this could eliminate the SF function that SF executes the page that SF stores. I realize that SF has got to do so when it provides no definition of what is to be done AFTER user initiates SAVE (or NEXT STEP), but it seems to me that piece can usefully be reformed and refactored! Best regards, John -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
