Expand my Community achievements bar.

Pros And Cons of Subforms and Groups?

Avatar

Former Community Member
Does anyone know of any pros and cons related to how things are grouped, either via an object group or a subform? Are there any specific reasons to use groups and not subforms - subforms and not groups?



For those who care to know a little more, not just questions...



In designing my forms I have taken this approach:



Groups (created by selecting Layout > Group) - I use groups for grouping simple objects (Text, Lines, Rectangles, etc.) which build the "static" portion of the form.



Subforms (created by drawing, or "wrapping" objects together) - I use Subforms for field objects (Text Fields, Numeric Fields, Decimal Fields, Check Boxes, Radio Buttons, Date/Time Fields, etc.) which act as the "live" or "dynamic" portion of the form.



I like this way of organizing the objects. It seems to make "sense" at least to me, and it also helps in terms of aligning objects, and so on. However, of course, it is not necessary to segregate the objects this much. So what is the preferred or recommended method? All opinions or suggestions are welcome!
1 Reply

Avatar

Former Community Member
Actually, there's a big difference between using groups and subforms to relate objects to each other although if you don't use any scripting and/or data binding, you probably wouldn't notice much difference.



Once you get into scripting and/or data binding, the use of groups and subforms makes a significant difference because groups (which are actually <area> XFA objects) are "invisible" when it comes to scripting and data binding.



This means that if, on a page, you had 4 text fields, each named TextField1/2/3/4, and TextField1/2 were grouped while TextField3/4 were wrapped in a subform (named "Subform") and you needed to access these text fields from the context of the page, you would do:



TextField1 OR TextField2


because they're grouped with an <area> tag which is transparent in the Object Model. If, on the other hand, you needed to access the 3rd and 4th text field, you would do:



Subform.TextField3 OR Subform.TextField4


because subforms are defined in the XFA Scripting Object Model.



The use of groups and subforms also affects data binding. That is, it affects the way XML data imported into your form is used to populate values of fields. For instance, if your data looked like this:



<data>

<TextField1>1</TextField1>

<TextField2>2</TextField2>

<TextField3>3</TextField3>

<TextField4>4</TextField4>

</data>


and your form had TextField1/2 grouped into a group named "Group", TextField3/4 wrapped into a subform named "Subform" and then another TextField3/4 which were siblings to the Subform and Group objects but placed
prior to the Subform object in the object hierarchy, importing the above data into the form would populate TextField1/2 in the Group object and TextField3/4 which are siblings to the Group and Subform objects -- not TextField3/4 which are wrapped in the Subform object.



Now let's say your data was as follows:



<data>

<TextField1>1</TextField1>

<TextField2>2</TextField2>

<Subform>

<TextField3>3</TextField3>

<TextField4>4</TextField4>

</Subform>

</data>


This would result in populating TextField1/2 in the Group and, as opposed to the first scenario, TextField3/4 which are wrapped in the Subform object.



This is a very simple example to prove a point. If you think about it a little, the implications -- especially concerning data binding -- are quite large. To help illustrate this further, I've attached a sample form with the hierarchy I described earlier as well as two data files: data1.xml is the first one I described in this post, while data2.xml is the second one. Try importing both into the form to see the differences in the results and then compare the object hierarchy in the Hierarchy palette with the nesting of the data nodes in the data files.



Finally, there's also the fact that subform instances can be created and deleted dynamically at runtime while groups cannot have instances. For dynamic forms, this is a big consideration.



Stefan

Adobe Systems