NYCPHP Meetup

[Rob Marscher]

This is an area where a flexible document database like MongoDB makes things a lot simpler. One document stores all of the configuration for the form and one collection can hold submissions with any variation of dynamic fields in them.

This post from NYTimes was inspiration to me a couple years ago: http://open.blogs.nytimes.com/2010/05/25/building-a-better-submission-form/

-Rob

On Jul 18, 2012, at 9:06 AM, Federico Ulfo <rainelemental at gmail.com> wrote:

> 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.ziogas at 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 <chsnyder at gmail.com> wrote:
> On Wed, Jul 11, 2012 at 4:26 PM, Anthony Wlodarski <ant92083 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20120718/e6ee7d4c/attachment.html>