Hi Robert,
Thanks for sketching the process. Too bad the idea of putting <nowiki>s into the template:RSS doesn't work, so I'm still stuck. Anyway Mediawiki hangs is the biggest problem - the whole server is kaput. Simple transclusion seems a good answer to do subforms, easier than keywords.Causes problems for SF perhaps, since it interprets <noinclude> and <inclueonly> in a particular, non-template way so maybe it's a good time to switch to <choose>, <add> <edit> and <delete> tags instead, and thereby 'allow' <noinclude> and <includeonly> to control what they conventionally control -- what is transcluded and what is not, whenever the page is transcluded. A little rankles me that <noinclude> and <include> have been semantically redefined by SF. Anway, <choose> can provide the content today found in SF <noinclude> sections, and provide a list of 'tools' ie 'action tags' on that page to wield against an existing page (or set of pages).
-----Original Message-----
From: Robert Michel [mailto:xologrim@hotmail.com]
Sent: Wednesday, August 19, 2009 12:22 AM
To: John McClure; semediawiki-user@lists.sourceforge.net
Subject: Re: [Semediawiki-user] [SF] Form transclusion - Mediawiki hangs

Hi John,
 
From my understanding of the workflow when displaying forms you get the following situation:
 
Normal Form Printing (without transclusion):
* the Special Page AddData/AddPage are invoked
* from there the formHTML (= parsing of the Form ) is invoked
* there all {{{...}}} are put into <nowiki>{{{...}}}</nowiki>
* only now the Form is put through the Wiki parser (which ignores all the {{{..}}} because of the <nowiki> tag
* now the remaining tags are only the {{{...}}} definitions, which are then parsed by formHTML
* the form is displayed
 
What happens when you transclude a form within another
* the Special Page AddData/AddPage are invoked
* from there the formHTML (= parsing of the Form ) is invoked
* there all {{{...}}} are put into <nowiki>{{{...}}}</nowiki>
* now the Form is put through the Wiki parser
NOW: Wiki parser transcludes the form, but since there the {{{...}}} are not in <nowiki> tags, it tries to parse them!
AND: this will probably go very wrong....
the remaining steps are probably not executed...
 
If I'm correct with that flow, there could be a solution:
* you could try to put everything with 3 braces ( {{{...}}} ) in <nowiki> tags. From my understanding, this should work. (setting $sfgDisableWikiTextParsing will not help, because the transclusion will not happen then...)
 
@Yaron: Could formHTML() be called recursively? If yes, it could be possible to support something like {{{subform:Form:mysubform}}} which calls formHTML() recusively opun parsing
alternatively, add a parser hook like {{#subform:<formname>}} which does the <nowiki> insertion around {{{..}}} before putting the form though the parser.
 
Hope that helps,,,
 
Robert Michel 

From: John McClure
Sent: Wednesday, August 19, 2009 8:59 AM
To: semediawiki-user@lists.sourceforge.net
Subject: Re: [Semediawiki-user] [SF] Form transclusion - Mediawiki hangs

Actually, I'm having trouble using {{template}}s as a workaround -- it's not correctly processing the {{{field}}}s specified in the template. The template is transcluded as:
 
{{{for template|RSS}}}{{Template: Form RSS}}{{{end template}}}
I had originally tried placing the {{{for template}}} & {{{end template}}} calls inside the {{template:Form RSS}} however Mediwaiki hung as soons as it prepared to switch to the AddData page. With those two calls outside the template, the result was that no input controls were displayed, rather the names of each of the fields were displayed!
 
Hope this helps. This moment, I don't see any workaround when there are common portions of a form. Neither transcluding subforms nor transcluding templates seems to do the trick. The result is that common fields need to be -copied- among all the forms that share them in common?
 
Thanks for any advice.