Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Data Binding for Idiots (me)

Avatar

Level 4

Hey everyone,

I've been asked to build a form that is way more complex than anything I've done in the past. I just wanted to ask the experts here a few questions before I get started, to make sure that I don't make any huge mistakes.

The complexity of the form lies in the huge number of nested repeatable subforms, the fact that it's three forms in one (which form being shown depends on a selection from a drop down list), and the fact that the form needs to be designed to export its data cleanly to xml.

As far as building the form goes, I'm comfortable with everything except for the exporting to XML. I've done this a few times, but I'm not sure that the assumptions I've made are correct. I've tried reading the help files, but I'm not sure I'm getting it.

Pretty much, I make use of a ton of subforms in order to make sure that the layout of the form works dynamically. I don't want all of these subforms to show up in the xml import. The way I've been doing it is to set the data binding on these subforms to 'No data binding.' Does this have any impact on how data is saved to the form? If I don't want the value of a field to be exported, can I set it's binding to 'no data binding', or will that cause prevent the values from being saved?

My final question is about the 'Use name' binding. Up until now, in past forms I've made sure that all fields have different names. This form is so large, and has so many similar elements that it would be useful to be able to resue field names in different areas of the form. For example, two of the versions of the forms has a section for associated addresses. The fields in these sections are the same. Can I name them the same thing, so long as they are within different subforms? Or will this cause a conflict when exporting/saving.

Sorry for the long post. In short:

1) What afftect does the data binding 'no data binding' have on subforms and fields, with regards to saved data and exported data? Are there any 'gotchas!' that I should be aware of?

2) What are the guidelines I should follow to ensure that I don't come across any naming conflicts? Do I just need to ensure sibling feilds aren't named the same, or should all names be distinct?

I would appreciate any help that you guys might be able to offer.

- Scott

1 Accepted Solution

Avatar

Correct answer by
Former Community Member

Scott,

1) No date binding means a form object is not included in exported XML. Data binding has no effect upon saving data when saving a form, the form will contain the data.

2) For me, rule #1 is use a schema and schema binding. It is worth the upfront investment in time. What you see in the schema is what you see in the output data, given a form object is bound to the schema. You can bind a single schema element to multiple form objects if you need to re-use data across sub-forms, also. Rule #2, again for me, is to explicitly define sub-form names to simplify schema binding and avoid name collisions.

I've attached a very simple form (with the schema embedded), the schema and exported xml to demonstrate.

Steve

View solution in original post

1 Reply

Avatar

Correct answer by
Former Community Member

Scott,

1) No date binding means a form object is not included in exported XML. Data binding has no effect upon saving data when saving a form, the form will contain the data.

2) For me, rule #1 is use a schema and schema binding. It is worth the upfront investment in time. What you see in the schema is what you see in the output data, given a form object is bound to the schema. You can bind a single schema element to multiple form objects if you need to re-use data across sub-forms, also. Rule #2, again for me, is to explicitly define sub-form names to simplify schema binding and avoid name collisions.

I've attached a very simple form (with the schema embedded), the schema and exported xml to demonstrate.

Steve

The following has evaluated to null or missing: ==> liqladmin("SELECT id, value FROM metrics WHERE id = 'net_accepted_solutions' and user.id = '${acceptedAnswer.author.id}'").data.items [in template "analytics-container" at line 83, column 41] ---- Tip: It's the step after the last dot that caused this error, not those before it. ---- Tip: If the failing expression is known to be legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: #assign answerAuthorNetSolutions = li... [in template "analytics-container" at line 83, column 5] ----