BillKarwin wrote: > > In general, you can do this only if your form and your database table > are trivial. For example, no multi-value form fields, no multi-value > data elements, and form fields have a one-to-one mapping to database > columns with the same data types and same names, etc. This is almost > never true, unless you're only developing a demo. > > Form processing is complex because information is complex. There is > no form processing that is as simple as you describe, while also > supporting the range of options that developers need. > > Regards, > Bill Karwin >
In a very simple form, this is how it could work: You distinguish three modes: add, edit, delete. This is always indicated, for example, by a parameter 'mode'. You give the fields in your form the same name as the columns in your database. You link this form to a db-table object. When you process the form, you first validate it (like you normally would) and when no errors have been found you poopulate the object of your db-table class with the values of the form (which is easy, because the names are the same) and save it. That still leaves some issues to deal with: - the (automatically) generated primary keys - multivalue form fields - forms that have multiple underlying tables The first is relative easy to tackle as well. Like the 'modes' field, you also determine which field will always contain the value of the primary key. If you have multiple db columns, you create this form-field as an array. Your db-table class should be (made) aware of these primary key columns and that's how you can populate them or extract them when necessary. Multivalue formfields: simply link them to other db-table objects and give them a special treatment. They would be ignored at first, since the 'main' table doesn't contain this column, so no problem there. Then it's just a matter of updating the underlying table in such a way that for the primary key of the 'main' form, only the posted values are linked. And i think the last one should be doable too. I was thinking this could probably be solved using subforms. That way you can isolate the values, map them to other db-table objects and process them in a similar way. I think this deals already with a lot of possible issues. What other 'big' issues do you see for this not be interesting to consider pursuing? Simon Walter-2 wrote: > > The only "oddball" is the id which would be automatically generated by the > db. > I think that one is relatively easy to solve (see above) Perhaps what would be useful is for Zend_Tool to output skeleton code for a > form using a db table to determine what fields are needed, etc. It would > be a > nice starting point, from which you could modify to suit your > requirements. > > Of course there are bigger issues and features to work on. Though, in the > future, that would be nice to have. > I don't agree. The main reason i'm using a framework is because it offers a generic solution to problems i'm faced with every day when i write code. Instead of writing lots of code over and over again, the framework provides a way to configure a few things so i can do the same thing with only a few lines of code. That saves me a huge amount of time and makes the code much more easy to maintain. That it also contains stand alone modules is a nice bonus but these should never be the main priority in my opinion. And this is exactly such a thing that could save so much time for so many people: i'm almost sure that every user of the zend framework is at one point or another writing and duplicating lots of code to process their forms, so this should be at the top of the list -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/generic-way-of-processing-forms-and-modifying-underlying-database-table-accordingly-tp3244032p3334854.html Sent from the Zend Framework mailing list archive at Nabble.com.
