usermodel that has one
profilenested within the
userobject, we must create a new instance of it and set it as a property in the call to
newProfileobject set in the first line of the action, we can
varscope it to clearly mark our intentions for its use.
editaction calling an existing object, our call would need to look similar to this:
profileproperty, you must include that association in the finder call with the
views/users/new.cfmwill end up looking like this:
profilemodel, which contain an extra argument for
association. This argument is available for all object-based form helpers. By using the
associationargument, Wheels will name the form field in such a way that the properties for the profile will be nested within an object in the
createaction does not change at all from what you're used to.
user.save()in the example above, Wheels takes care of the following:
usercalled profile with the
profiledata stored in an object.
editscenario, this is what our
updateaction would look like (which is very similar to
usercan have many
addresses. Furthermore, we know that each
userhas only one
usermodel, let's add an association called
addressesand also enable it as nested properties.
addressestable contains a foreign key to the
userid, Now in the
addressesmodel, let's associate it with its parent
Userand also enable it as nested properties.
addressin the array.
editscenario, we just need to remember to call the
includeargument to include the array of addresses saved for the particular
views/users/_address.cfm. Wheels will loop through each
addressin your nested properties and display this piece of code for each one.
position. Without having a unique position identifier for each
address, Wheels would have no way of understanding which
statefield matches with which particular
address, for example.
position. This value is set automatically by Wheels for each iteration through the loop of
addressesis exactly the same as the code demonstrated in the Saving the Object and Its Nested Properties section earlier in this chapter.
customers' subscriptions in the
subscriptionsjoin table, one approach is to loop through data submitted by checkBoxTag()s from your form, populate
subscriptionmodel objects with the data, and call save(). This approach is valid, but it is quite cumbersome. Fortunately, there is a simpler way.
customermodel for this example:
editaction in the controller at
customerwith its associated
subscriptionsincluded with the
includeargument. We also need all of the
publications in the system for the user to choose from.
publicationsto assign to the
views/customers/edit.cfmis where the magic happens. In this view, we will have a form for editing the
customerand check boxes for selecting the
<fieldset>for Subscriptions, which loops through the query of
publicationsand uses the hasManyCheckBox() form helper. This helper is similar to checkBox() and checkBoxTag(), but it is specifically designed for building form data related by associations. (Note that checkBox() is primarily designed for columns in your table that store a single
true/falsevalue, so that is the big difference.)
objectNameargument passed to hasManyCheckBox() is the parent
customerobject and the
associationsargument contains the name of the related association. Wheels will build a form variable named in a way that the
customerobject is automatically bound to the
keysargument accepts the foreign keys that should be associated together in the
subscriptionsjoin table. Note that these keys should be listed in the order that they appear in the database table. In this example, the
subscriptionstable in the database contains a composite primary key with columns called
publicationid, in that order.
updateaction is fairly standard for a Wheels application:
customerstable with any changes submitted in the Customers
subscriptionstable depending on which check boxes are selected by the user in the Subscriptions