RE: generic HTML forms

[Peter Reitsma]

Title: Bericht

Hi Henk,

 

The package looks neat, thankx !

 

As for the postprocessing, I intend to store the form entries in a denormalized way in database table/mmbase node. We can set a restriction to e.g. max 15 fields per form and then store each form-entry in a record, each answer in a column (field). Also we will store the submittal date for each form and possibly the IP-address.

 

This is possible since there can be only one answer to each question (multiple selects are not allowed) in the form. A restriction for this to work is that the form definition remains unaltered, once it is published.

 

I think I have a good case for denormalisation here because storing the form entries into a two node structure with a posrel (e.g. formresults and formanswers) will have a negative impact on the performance of the back-end function where editors want a quick overview and speedy filter functionality on the results which are expected nto run into the thousands and more for some forms (better not have triple joins dish up these results)

 

The form entry processing logic will be in the same template that renders the HTML form. Not very MVC but handy since we can have the form submit itself and keep all logic concentrated.

 

Now, the only thing that worries me about this solution is the scriptkiddies. In the case of the poll worst they can do is messing up the poll results. In this case however, a malicious script potentially blows up the entire database since every form-entry results in another db record being added.

 

I'd be interested in any tips on countermeasures against this. Cooky or IP-based checking won't do. Somehow we should detect sudden quick increases in incoming form-entries and upon this event temporarily freeze the processing. Or does somebody know how to implement a solution with the picture with a code on it that the end-user has to type over in a form field ? Like Yahoo and Hotmail registration do, that looks pretty neat to me.

 

Rgrds> Peter

 

 

 

 

-----Oorspronkelijk bericht-----
Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Henk Hangyi
Verzonden: vrijdag 7 mei 2004 9:14
Aan: [EMAIL PROTECTED]
CC: Yvette van Dijk
Onderwerp: RE: generic HTML forms

Hi,

 

The html form functionality has already been implemented, however it has no postprocessing. Entries are just send by email.

 

See the package MyMailform under

 

http://www.mmbase.org/?portal=205&page=19638

 

An example of the mailform in use is:

 

http://www.mmbase.org/?portal=205&page=25614

 

If you would like to add postprocessing to the form I would like to help design and implement it.

 

Regards, Henk.

 

T. +31-(0)6-29054903
E. [EMAIL PROTECTED]
I. http://www.mmatch.nl

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Ockeloen
Sent: Thursday, May 06, 2004 12:28 PM
To: [EMAIL PROTECTED]
Cc: Yvette van Dijk
Subject: Re: generic HTML forms

On May 6, 2004, at 11:55 AM, Peter Reitsma wrote:

Hi,
 
We want to add a generic HTML form function to our MMBased CMS. This functionality will enable editors to define end-user targeted HTML forms consisting of any combination of text, checkboxes, radiobuttons and single selectbox fields in any order with prompts and basic validation options. For radiobuttons and selectboxes the editor should be able to define the list of values. Furthermore, back-end functionality is needed in which the editors can view, analyse and aggregate the form entries made by end-users on his particular form. Another requirement is the possibility to export these entries into CSV or Excel format.
 
I more or less envision how I could design and build it but my question is whether this functionality is already (partly) available somewhere ?
 
Also tips and ideas on this are welcome.
 
Regards and thanks in advance,
 
Peter
 

MMbase has/had some things for scan based sites, i personally like the idea but i wonder how this would work. My first guess would be a 'preprocessor' that generates the needed taglib pages. Creating special new functions for this doesn't sound to smart and not easy to maintain. Having it create 'normal' taglib commands means its easer to update and maintain also means you can allways change the results by hand.

Daniel