Last modified: 2011-12-16 13:15:49 UTC
Created attachment 8816 [details] Patched SF_FormPrinter, based on 2.2 This enhancement is a continuation of this upgrade: http://www.mediawiki.org/wiki/Extension_talk:Semantic_Forms/Archive_February_to_March_2011#Copying_a_form_result_into_an_another_on_submission And is thus a solution to the following situation, when one want to have fields in a template that are themselves populated by a list of templates, and want to be able to edit that using "nested multiple forms". http://www.mediawiki.org/wiki/Extension_talk:Semantic_Forms/Archive_September_to_October_2010#Nested_forms The logic is to have in the main form a hidden field with a "placeholder" attribute. Then, a multiple-instance form is defined outside of the main form, as usual, but also has a "placeholder" attribute set at the same value as the hidden field (let's say we talk about the Mayors parameter). When the page is edited with the form, the list of templates set in the Mayors parameter are taken out of the Town template, and appended at the end of the data, as if we were in a normal multiple-instance form situation. A hidden field is inserted in the HTML at the mayors position, set with a special "@replace_mayors@" value, and a "@insertpoint_mayors@" text is also inserted. Then all the HTML continues to be generated. Upon coming on the Mayors templates, these parts are processed by the separate multiple-instance form defined for this kind of templates, but are not appended to the end of the current HTML as usual. All the HTML corresponding to these templates is reinserted at the @insertpoint_mayors@ position, which finally gives the illusion to have a multiple-instance nested form inside the main form once everything is displayed. On form submission, the fields values are translated into medaiwiki templates as usual, and the Mayors parameter is first set to "@replace_mayors@" (the hidden field value), but then the list of templates generated from the multiple-instance form is reinserted in this position. I set up a test instance here to see show it works: http://www.saintseiyapedia.com/wikitest/Main_Page user/pass: test/testsmf Issues: 1.it is only possible to to 1 depth level of nested templates (but possible to get as many nested templates on the base depth as you want). Putting a placeholder system in something that is already a placeholder won't work. To do that, a lot of refactoring into a recursive solution would be needed. I tried to not touch the overall logic. Notes: 1. Normal multi-instance forms still work and can even be used at the same time as placeholder ones. By the way, since this fix tries to not alter too much the original logic, some code duplication was done at the end of the multi-instance temaplte part, but a better refactoring woul be to remove the normal multi-instance logic, and use the placeholder logic instead, since the original functionality could be easily mimicked by putting a dummy placeholder value at the end of the currently processed HTML. 2. Most explanations are in the code comments, usually delimited by //addition and //remove tags
Hi - this patch looks extremely interesting. Two thoughts: - would it be possible to change the form syntax, so that instead of using the "placeholder/placeholder_name" parameters, it had syntax that looked like: {{{field|town_mayors|hidden}}} ...and: {{{for template|Mayor|embed in field=Town[town_mayors]}}} ? I think that would be easier for users to understand. - Could you also include, besides the complete file, a patch file showing just the changes? If you have SVN, you can do that by calling "svn diff SF_FormPrinter.php > patch_file". Thank you, and I look forward to including this functionality in the next version of SF.
Hello, I modified the code so that it works with {{{field|town_mayors|embedder}}} and: {{{for template|Mayor|embed in field=Town[town_mayors]}}} Actually, using only "hidden" would make difficult to especially identify this field asa placeholder to embed a field. Since at form generation the field would actually contain the list of Mayor templates, there wouldn't be any way to tell whether it's supposed to be something to delegate to an another Form or if it's a normal variable. Right now the process is done on the fly, so if a field is seen as a placeholder through the "embedder" attribute, the data is moved out of the template and added at the end of the parsed string, so that it will be later picked up by an another approriate form. To get the process working only with a "hidden" attribute, we would need to have a first loop parsing all the code to detect which forms are here, where are the placeholders and make a hierarchy of things to nest, and from that identify which hidden fields are true hidden fields, and which fields are placeholders. That would need large structure modifications (but would also allow infinite level of nest forms I think). Right now the limitation with the "on the fly" parse is that nested forms have to be declared after the main form that will embed them. It is possible to embed multiple forms in a base form, but trying to embed a form into a form that is itself embedded in something else doesn't seem to work. For that,we would need to use the first parse loop described above, and then probably generate everything recursively. About the current syntax, if the user mistakes the "embed in field" attribute's value, the Templates parsed by this form (ex: Mayor) will still be taken out of the main template and parsed as if it were normal "multiple forms", and then saved outside of the main template. Fixing the "embed in field" attribute's value, reediting the page and resaving it will reintegrate these templates (Mayor) into the approriate field in the main template (Town). It can be used deliberately as a trick to grab and move this kind of data inside/outside of templates.
Created attachment 8876 [details] SF_FormPrinter patch based on 2.2.1
Created attachment 8877 [details] SF_Utils patch based on 2.2.1
Created attachment 8878 [details] SF_FormPrinter already patched based on 2.2.1
Created attachment 8879 [details] SF_Utils already patched based on 2.2.1
Hi LY, Sorry for the delay - and thanks again for this awesome patch. I finally checked it in to SVN just now, with some modifications: I moved the new functions into SF_FormPrinter.php, so now that's the only modified file; I changed the names of some of the functions and variables; I changed the parameter "embedder" to now be called "holds template"; I changed some of the comments and formatting; and I did some refactoring of the code, creating a new function, multipleTemplateInstanceHTML(). But the actual flow of the code is exactly as you created it. This looks great, and I think this will have a big impact on how forms are structured. There's only one problem that I see with it at the moment, which is that, if you have a "label=" parameter for the multiple-instance template (which many people do), the <fieldset> tag for that template doesn't move to the new location in the form. You can see the problem here, with this test form I created: http://discoursedb.org/wiki/Special:FormEdit/Source2/Test_source Here's the definition of that form: http://discoursedb.org/w/index.php?title=Form:Source2&action=edit Do you have any thoughts on this? If you know of a fix, another patch would definitely be welcome. -Yaron
Hi Yaron, Thanks for pointing this issue. Indeed, it seems that I overlooked the label attribute. I made a fix for that based on the latest SVN version, I will upload it tonight.
Created attachment 9090 [details] Patch to fix the label issue - based on svn rev 97884 Hi Yaron, Here is the patch.
Awesome!!! The patch works perfectly. Thanks for your contribution here, and I'm really looking forward to this feature being officially released, in the next version, which will hopefully be coming out soon. By the way, to answer one of your original points, I don't think the fact that it only allows one level of nesting is a big deal - that's all that most people need, and anything more than that is probably too complex a set of information to try to include on a single wiki page.
Marking this as "fixed", which I should have done a while ago.
