It depends. For dynamic form I prefer to use 3 tables form(form_id,name,action) field(field_id,form_id,name,type : [text,textarea,checkbox,select ... ], default,validation : [required,max=,min=,email,numeric,alphanumeric ... ], option ), option say if the value are coming from field_value, another table, or array. field_value(field_value_id,field_id,name,value)
Another pain in the neck is to save the input from a form, in that case you may need a table with the static information and one with the dynamic information, for example: result(form_id, firstname,lastname...) result_field(form_id,name,value) Or if you want to save with dynamic fields I suggest to use RedBean, an ORM that will save your time. Also to create the form you need to create a form generator, if you are lazy you can use mine: http://www.rainframework.com/User-Guide/Library/Form (this site is down because I'm moving the server... check in 1 hour or 2) Federico On Wed, Jul 18, 2012 at 8:35 AM, Petros Ziogas <petros.zio...@gmail.com>wrote: > I prefer to create a "settings" table where I store all the bits and > pieces that need to be configurable but are not that frequently changed. > > If you want to make everything translatable, I would not tie it to a > settings table but rather set up a global translate procedure that would > apply to these settings but also to other elements of your application. > > I have found that deciding on some general rules around these issues can > make your life much easier. Jumping from project to project and realizing > that the countries are always in the settings table and always called in a > curtain way can make you day and save you some hours in debugging and > developing. > > my 2c > Petros Ziogas > > > On Thu, Jul 12, 2012 at 5:54 PM, Chris Snyder <chsny...@gmail.com> wrote: > >> On Wed, Jul 11, 2012 at 4:26 PM, Anthony Wlodarski <ant92...@gmail.com> >> wrote: >> >> > For example, we ask users to select their Ethnicity when filling out >> one of >> > our forms. This includes the values: Prefer not to say, African >> American, >> > Asian, White, East Indian, Hispanic / Latino, Middle Eastern, Native >> > American, Other. Where would you store these options? >> >> Where you store them is a matter of style. I like using blocks of JSON >> for this, personally, but others would cringe at the parsing overhead. >> >> But however you keep them, I think the ideal solution needs to >> accommodate two things: >> >> 1) Localization/internationalization - if you're just storing American >> English values, you're limiting yourself. The labels for an Ethnicity >> selector can even vary region by region within the US. You may need to >> keep the choices the same in order to normalize the database, but the >> labels need to be translatable. >> >> 2) Meta-data about the selector itself. Multiple choice? An Other... >> field? Is it ideally a <select> or a series of radio buttons / >> checkboxes? Is there an instruction that goes along with the field? A >> default value? >> _______________________________________________ >> New York PHP User Group Community Talk Mailing List >> http://lists.nyphp.org/mailman/listinfo/talk >> >> http://www.nyphp.org/show-participation >> > > > _______________________________________________ > New York PHP User Group Community Talk Mailing List > http://lists.nyphp.org/mailman/listinfo/talk > > http://www.nyphp.org/show-participation >
_______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show-participation
