Development

EmbeddedForms (diff)

You must first sign up to be able to contribute.

Changes between Version 1 and Version 2 of EmbeddedForms

Show
Ignore:
Author:
dmccullough (IP: 128.228.113.48)
Timestamp:
08/25/10 18:48:06 (7 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • EmbeddedForms

    v1 v2  
    11= Introduction = 
    22 
    3 Due to the heavy normalization of our database structure, our high level business objects are composed of a number of smaller, related data points that all connect to a main Id that exists in a table of only Id's (eg, agPerson). In certain instances, we can use Symfony's auto-generated lists to get data into the lower level tables, but, for sub-objects that are very complex in their own right, the use of embedded forms is necessary. Embedded Forms, at least in the way we'll need to be using them, are not an extensively documented feature Symfony. They allow you to attach the form for a sub-object of related-object into the form (and then page) of your main object. These forms then act as one form from the frontend, and add, update, or delete data from multiple database tables with one submit action. 
     3Due to heavy normalization in a database structure, high level business objects are sometimes composed of a number of smaller, related data points that all connect to a main Id that exists in a table of only Id's (eg, agPerson). In certain instances, we can use Symfony's auto-generated lists to get data into the lower level tables, but, for sub-objects that are very complex in their own right, the use of embedded forms is necessary. Embedded Forms, at least in the way we'll need to be using them, are not an extensively documented feature Symfony. They allow you to attach the form for a sub-object of related-object into the form (and then page) of your main object. These forms then act as one form from the frontend, and add, update, or delete data from multiple database tables with one submit action. 
    44 
    55All of the research and development on embedding forms has aimed at implementing the full functionality of the agPerson business object, specifically enabling a person to have one or more names (in our test case, Given, Middle, Family, Maiden, and Alias). This documentation will use agPerson, agPersonName, agPersonNameType, and agPersonMjAgPersonName for its basis and examples. 
    282282The __construct function is the counterpart to line 28 in agPersonForm and completes the passage of the agPerson object to agEmbeddedNamesForm. 
    283283 
    284 The configure function is where the bulk of the action happens. Doctrine::getTable on line 14 gives this class access to all values in the ag_person_name_type table, which are needed to define labels and hidden field names for the forms that are embedded on line 28. More information on accessing an entire set of table values can be found here. 
     284The configure function is where the bulk of the action happens. Doctrine::getTable on line 14 gives this class access to all values in the ag_person_name_type table, which are needed to define labels and hidden field names for the forms that are embedded on line 28. 
    285285 
    286286The two loops in lines 16-29 handle determining the form titles and default field values and the embedding of the forms. The name_types that have been accessed on line 14 are looped through, creating a new agEmbeddedAgPersonMjAgPersonNameForm as $emb for each instance of ag_person_name_type, and assigning a default value of that instance's Id to the new agEmbeddedAgPersonMjAgPersonNameForm's person_name_type_id.