Management of Nested Resources

This release provides more flexible DB schema support and improved content management for complex data structures. In the current release, nested beans will be given their own generated manager/domain class, and domains will make calls into each other to accomplish joins of the type described below.

Note: Nested beans occur when the primary resource table (TABLE A) is joined to a secondary table (TABLE B), the join is not to the primary key of the secondary table, and more than one column is included in the resource from the secondary table.

Say that you want to content manage TABLE A and TABLE B, where there is a one-to-many or many-to-many relationship between TABLE A and TABLE B, and more than one column from TABLE B is included in the resource. At runtime, you may want to use a resource that includes columns from both tables, for the purpose of selecting content from one table with conditions on the other table.

In previous versions of WPCP, there is no way to author TABLE B as a child of TABLE A using the generation wizard templates, and therefore, the resource that is required for the runtime behavior described above is not useful when authoring TABLE B. In addition, for the many-to-many case, you would have to be aware that altering the child of one row in TABLE A may alter the child of another distinct row in TABLE A.

For these reasons, the new model involves authoring TABLE B apart from TABLE A, as its own resource collection. Although TABLE B can be viewed as a child of TABLE A, update access to TABLE B through TABLE A's manager is not supported in this scenario. Instead, updates to TABLE B would occur directly through a manager for TABLE B. Although Table B and Table A are authored separately, when you preview the project's pages and rules at authortime, the complex resource is represented as a single entity.

 

Back