Form Builder storing results as WDDX

I'm going to re-write it to create tables. I think the individual records as wddx packets could still be a problem. Mainly because forms can be edited after results have been collected which would mean the field list in each result could change. I can think of ways round this but It could still potentially be a lot of reworking.

Thanks Ian

cf_matt wrote:
> Hmm i hadnt thought about breaking each record into a wddx packet, it would
> make it hard on cf to display a list of results though as you would have to
> parse each packet for a value.

You more or less have to do that now. You have to parse each record
node of the larger WDDX packet. I don't think it would be that large a
change to parse a group of WDDX packets for the list.

> I am starting to think that if i'm going to do the whole thing with name and
> value pairs then i would rather re-write the whole thing to create individual
> tables.

My instinct says this is probably a more robust and scalable solution.

Hmm i hadnt thought about breaking each record into a wddx packet, it would make it hard on cf to display a list of results though as you would have to parse each packet for a value.

I know what you mean about huge amounts of records not really being a problem.

The scenario I have is that clients are using the form builder for employment forms, so the forms have about 100 fields (i'm not joking). so that would be 100 records per individual entry.

I guess it will still be faster than using wddx.

I am starting to think that if i'm going to do the whole thing with name and value pairs then i would rather re-write the whole thing to create individual tables.

cf_matt wrote:
> Ian
>
> yes i think thats right
>
> so i have:
>
> form_id | form_name | form_recordset
> 1 enquiries <WDDX>
>
> I did think about storing name and value pairs in a table but then that would
> be huge amounts of records
>


First of all, don't be afraid of a huge amount of records. That is what
databases are designed to deal with. A great many very smart people
have spend a great many hours making database management systems very
efficient at processing huge amounts of records for the past fifty years
or so. Personally, I trust their work to be more complete then anything
I can cobble together on my own.

Secondly, I would at least break it up so that each complete form submit
is one record in the database. Then at least you are dealing with a
constant sized WDDX packet, not one that is growing with every new
record append to the data.

Ian

yes i think thats right

so i have:

form_id | form_name | form_recordset
1 enquiries <WDDX>

I did think about storing name and value pairs in a table but then that would be huge amounts of records

Why don't you save form results direct to the database? Do you really need WDDX?

OR you can try to use JSON or direct XML.

You can check the page politico.com as an example.

This site uses ColdFusion but you can not figure out easily.

Because of having huge load on servers, they prefer to generate news page as HTML from database and save as static pages. That does not means that these pages are not dynamic. They are but just not generated on fly.

This allows less load because of not generating all the pages in realtime. The admin just push a button and generate all the pages 4 times a day etc. I think your forms are not changing everyday and you may consider to generate these dynamic forms daily or on demand basis and use them in your application without having the load to generate them dynamically in every request.

Also if i stored the results as html, i wouldnt be able to ever change the output or easily show the output, it sounds messy.
the data is queried also (i convert the wddx to cfquery). I know its very hard to know without seeing the code but this wddx packet is definately the bottleneck and if there was an alternative or faster way of storing the information or dealing with this information then that would really help.
I've started to give the option to archive the information but on a form that has say 50 fields it doesnt take long for the wddx results to get huge!

I didnt originally design the form builder for forms of this size but it is being used this way and is so much faster than developing the forms with cfml.

You can save these forms in HTML format and include them whenever you need them.

How you generate ehse forms is also very basic logic. After deciding latest form status in your admin, you can push these latest forms as HTML into a directory etc. with a "Generate Forms" button. This only works once on admin interface and you do not have to do this work in realtime for every request.

I hope it is clear. :)

I had a same kind of issue and at the end I decided to generate forms in static HTML via admin. Whenever they finished editing forms I generated HTML for the forms with a "generate" button and saved the generated forms in a directory and embedded (included) these forms in the application pages with a simple parameters.