Summary: Talk page for BuildForms.
Users: (View? / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.


  • problems with select-option-inputs: 'any command close the list' (see text above) - this does not work satisfiable! for example when using tables-markups for the form-design, the </select> ending-tag will not be on the right place (just in the next cell, destroing the design we want).
    Yes, this can be a problem, use the command (:frmendselect:) to handle particular cases, that command being not compulsory PRZ
  • it will crash on (:frminit:) (:frmend:) with no intervening blanks. Joachim Durchholz April 10, 2005, at 04:30 AM
  • storing the form data in a file with a fixed name creates a race condition. If two forms are submitted at the same time, the data of one form will overwrite that of the other before it's processed. It would be better if the recipe simply passed the data to a CGI (pmwiki.php would be fine). Joachim Durchholz April 10, 2005, at 04:30 AM
    It might have been much simpler to do so, but in that case, how can I memorize the data to be presented again to the user?
    The person who have asked for this functionality creates a page for each user (using the form as a template), so don't face this problem.
    This recipe is not session based and so, I see no solution to face a 'user competition'. There is anyway a parameter to not store values (documented ?)
    I think it goes ahead my initial intent. I have no clear idea of all the uses of this recipe (...); my intent was to have an easy way to make a configuration page which don't normally face multiuser usage. PRZ
    Basing the recipe on sessions would be trivial: simply store the information in $_SESSION['BuildForms']. PmWiki already uses $_SESSION for other purposes, so it's safe to assume that session support is available.
    If the receiving CGI isn't written in PHP, the usual technique is to use hidden input fields.
    Storing the data in a file just complicates things. It causes additional disk writes, admins need to configure another writable directory (can be a hassle, and they may have long forgotten what they did when installing PmWiki), and it doesn't buy the CGI script anything (it reads the data from the .prm file instead of from an environment variable, that's all).
    (Sorry for responding late, I don't monitor RecentChanges pages.) Joachim Durchholz June 30, 2005, at 03:15 AM
  • Is there a possibility to hide the text entered in a field, to recieve a password for example ?
I have been working with this script, and it seems to work nicely offline. But I when I uploaded to my server, I got these php errors:
Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in 
/home/fastst/public_html/fastwiki/system/cookbook/buildforms.php on line 314

Warning: fsockopen(): unable to connect to :80 in /home/fastst/public_html/fastwiki/system/cookbook/buildforms.php on line 314

Warning: Cannot modify header information - headers already sent by (output started at 
/home/fastst/public_html/fastwiki/system/cookbook/buildforms.php:314) in /home/fastst/public_html/fastwiki/system/pmwiki.php on 
line 796

Warning: Cannot modify header information - headers already sent by (output started at 
/home/fastst/public_html/fastwiki/system/cookbook/buildforms.php:314) in /home/fastst/public_html/fastwiki/system/pmwiki.php on 
line 797
It then proceeds to process the script. Any suggestions? Caveman

Talk page for the BuildForms recipe (users?).