Page MenuHomePhabricator

Dynamically using field values within the form
Open, MediumPublic


I would like to use the values in a preloaded page to control the display of the form, but I don't see how to query those values in my form when the page has not yet been created. The values could be stored by the form's template and then queried using #ask, but that's not possible until after the page is created (and sure would be inefficient in many cases). I'm wondering if one approach is a new SF parser function to query those variables specified in the query string or in preloaded data, eg <nowiki>{{#formvar:templatename|varname}}</nowiki>. Maybe there's a workaround for the time being?

This new feature would eliminate many many forms that are merely minor variations on a theme, e.g. making a field mandatory that is usually optional. I note that if the category were an input, then the form could look up the category and easily format those fields corresponding to its data model.


Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:34 PM
bzimport set Reference to bz28260.

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.


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:
{{#formvar:Minor|Category}}=Boy OR {{#show:{{PAGENAME}}|?Category}}=Boy

Boys NameGirls 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}}


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

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.


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.