Can you list some other ways you'd like to be able to use field values within the form, besides setting whether or not another field is mandatory? I'd like to get a better sense of the scope of what you're asking about.

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 3. Is there one?

How about one form:Minor with no templates at all:
{{#ifexp:
{{#formvar:Minor|Category}}=Boy OR {{#show:{{PAGENAME}}|?Category}}=Boy

}}

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

}}
{{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

Okay... I think you could have just said, "set text in the form based on a field value" and left it at that, but thanks. :) By the way, if what you describe as the "category" field is set by a dropdown or radiobutton, this can already be done via the "show on select=" parameter.

As a consequence certain templates can be eliminated altogether, eg
the annoyingly simple templates that do nothing but {{#set}} values:

{{{for template|Minor|nowrite=nowrite}}}
...
Category: {{{field|Category|values from property=Category}}}
...
{{{end template}}}

{{{for save step|x}}}
{{#set: Category={{#formvar:Minor|category}} }}
{{{end save step|x}}}

& about the Show on select approach..
Yes that's an option but life gets really difficult very fast when there's more than one string whose visibility is to be controlled.

Changing to a more descriptive title.

John,

for avoiding the annoyingly simple templates that do nothing but {{#set}} values try

{{{for template|#set:}}}
...
Category: {{{field|Category|values from property=Category}}}
...
{{{end template}}}

Nice to know - many thanks! (didnt see this in the doc)

I suppose {{{for template|#set:}}} means
(1) multiple & strict parameters are not applicable
(2) any fields withOUT values from property or show on select are meaningless
Anything else? It's interesting to have this capability/

It is a hack. SF was never intended to directly create parser function calls, so it is not in the docs.

Anyway, you are right, that anything specific to templates will not work, e.g. the "strict" parameter. The "multiple" parameter however should work, there is nothing wrong with having multiple #set statements in an article.

I guess you will Have to play with it to see what works and what does not.