I posted something similar a while ago and have been contemplating the "best" method for way too long. I'm killing my brain and I think working further away from a solution. Let me explain the situation: - You would create a mailing list subscription form - You would select which lists to include on the form (let's say A and B) - You would select which fields to include on the form (let's say Name, Phone #, Country) Now in fact Name is attached to A, and so is Country - but also made available to B. So it makes sense to have each of them on my form since I have list A and B on it. Phone #, on the other hand, is attached to list C which was not included in the form. As I've come to realize though, it isn't such a horrible thing to have a user fill in an extra field that basically just gets discarded afterwards in the case that the creator selected a field that doesn't match with a selected list. Follow me so far? Hope so! On the backend certain fields can be marked as required - let's just assume every field is marked as required. The issue is that not every field was selected to be included, so we can't tell the user that field 'Address' wasn't filled out when it wasn't selected to be included. So, what is the best way to make sure the form/backend will know what data is supposed to be sent? I thought about storing the form information in a database, but as people create more and more forms this database would get overloaded and people would lose track of anything they wanted to go back to. I then thought about creating an array (of the lists, fields, etc.) and serializing that, then including it in a hidden field in the form. I don't want to store it as it's open-viewable serialized state... but most encoding methods end up with a longer/same length string... ideally something shorter would be nicer . So those are the two methods I thought about. Either one of those or something else, what do you think is the best way to set everything up so that the resulting form processor will know what data is to be expected and can validate/process based on that? I hope I made enough sense.... haha
Ya, and what they have done is stored each created form in the database. Ideally I don't want to do this because once you have a bunch of users using it and creating the forms, then you end up with a long messy list of created forms... And it doesn't make sense to relate the form to a user (many/most will want to use that same form) or to a list (as they can include multiple lists)
The common OO approach is to have a series of tables * forms - stores the names of the forms that exist * fields - stores the name and type of fields that exist and the form_id, and a sortorder * fields_data - stores the field_id and the data held against the form then the forms can be generated by just passing down the relevant form_id