One of the nice things about the cfwheels framework is the ability to build forms that map directly to a model object using form helpers. On the "receiving" end (in your controller), you have access to a key in the params scope that is a nested structure of data that'll line right up with your model. This stuff makes scaffolding CRUD forms a serious layup.
#select(label="org", objectName="contact", property="org_id",options=orgs, valueField="org_id", textField="org_name",includeBlank="Select an Org")#
Recently, I have been working on a standard set of scaffolding templates to take the CRUD generation to a whole new level. Along with a few methods in the base controller (and some helper methods for the view) I've worked in generic code to include pagination, column header sorting and filtering in all the generated templates. While I was working on the filter controls, I realized I'd seriously like to have a nested param structure with all the filter fields contained within. But the form helpers are specifically for mapping fields to a model object, and I'm not doing that. So I looked further into how wheels constructs those nested params for the form helpers and low-and-behold, i found a simple little function that when used with the right naming convention, tears it up on the form-field parsing front. And, it's called on every request automagically, so you aint gotta do nuthin to make it work. Schvinnnng!
Looking inside /wheels/dispatch/request.cfm i found the $createNestedParamStruct() method. After discovering how it expects and parses field names, i then reverted back to my filter form and started naming fields like this:
#selectTag(label="type",name="filters[label_id]", options=labels,textfield="label_description",valueField="label_id")# #selectTag(label="org",name="filters[org_id]", options=orgs,textfield="org_name",valueField="org_id")# #selectTag(label="contact",name="filters[contact_id]", options=contacts,textfield="full_name",valueField="contact_id")#
Notice I'm not using the objectName or property arguments to the selectTag function (like we did in the select(0 function for the model object mapping) - selectTag doesn't tie the form field to a model "object" But, by using the [] notation on the field name, wheels automatically creates a sub-structure in the params scope when the post occurs... so by the time I can even get my hands on these any of these params in the controller, it's already neatly encapsulated in a sub-structure named "params.filters"