Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

AEM 6.2 Forms and element id's.

Avatar

Level 4

I'm noticing that in 6.2, the binding that is built for the form items doesn't match the id of the items. When I use the id returned by calling var anId = $(this).parents('.guideFieldNode').data('guideViewBind') then take the returned id and then call guideBridge._resolveId( anId ), it does not find the element. The id for the element in the page does not match the id created in the guideBridge._guide._modelTemplateCasheStore._modelIdCache list of items. 

When the components are built in the JSP page, the binding is done using the ${guideid} variable. This id is very different that the id that is in the cache. 

Any idea what I need to do in order to fix this?

9 Replies

Avatar

Level 4

The id of the HTML element from ${getid}:

guideContainer-rootPanel-fragmentPanel-contact-fullLegalName-first___

The id in the guide store:
guideContainer-rootPanel-your-info-contact-contact-fragmentPanel-contact-fullLegalName-first__
 

Why don't they just use the same method to generate both id's so you can match them up?

Avatar

Level 3

This is a special case for fragments and hence you are seeing different Ids. Consider the case where you drop a fragment twice in the form side by side, as per the jsp code, the id would become the same and it would be difficult for the runtime to differentiate between the two. So in the case of fragments we change the id when fragment is loaded. 

Also this logic is internal to Adaptive Form and can be changed anytime. It is not recommended to depend on the id to do anything. The recommended approach is to add a CSS Class via CSS Class Property in your Field Dialog and access that using the class selector.

Regards

Varun Dua

Avatar

Level 4

The problem is that there each item is on the form once. We hide and display fragments with javascript. The problem is with validation because the list of failed elements returned from the guideBridge validation method has ID's that don't exist on the page, you can't use the somExpression to resolve the element, and the _visible flag is always set to true even though the the elements are hidden. It is almost impossible to keep the form controls consistent with the guideBridge in this case. This is all so messy that it is hard to leverage adaptive forms for dynamic content. 

Avatar

Level 4

The other problem I'm seeing is that the guideBridge isn't being updated with the form data so when the validationExp is called, the values aren't there. What should I be looking for to correct this?

Avatar

Level 4

In stepping through the javascript in the guideRuntime, the edit controls aren't being associated with the JSON model where the values are validated and stored so the validation expressions aren't being stored and the form is never valid because the controls are all marked as required.

 

What should I be looking for to get the controls to properly associate?

Avatar

Level 3

> The problem is with validation because the list of failed elements returned from the guideBridge validation method has ID's that don't exist on the page, you can't use the somExpression to resolve the element,

I am still not getting, maybe some code you provide can be helpful. With SomExpression you can get hold of the HTML element like this

var errors = []; guideBridge.validate(errors); errors.forEach(function (error) { var field = guideBridge.resolveNode(error.som); var $field = $(field.cssClass); //your code })

We have a wrapper JavaScript object on top of JSONModel object which we call as our Model object. The HTML controls are bound to that model element. Can you share some code which can help me identify the problem and how you are using guideBridge. All the stuff you can do with guideBridge library can be achieved without it as well (except submission). The library is generally used when you want any external applications to connect to Form Model.

Avatar

Level 4

varundua wrote...

> The problem is with validation because the list of failed elements returned from the guideBridge validation method has ID's that don't exist on the page, you can't use the somExpression to resolve the element,

I am still not getting, maybe some code you provide can be helpful. With SomExpression you can get hold of the HTML element like this

  1. var errors = [];
  2. guideBridge.validate(errors);
  3. errors.forEach(function (error) {
  4. var field = guideBridge.resolveNode(error.som);
  5. var $field = $(field.cssClass);
  6. //your code
  7. })

We have a wrapper JavaScript object on top of JSONModel object which we call as our Model object. The HTML controls are bound to that model element. Can you share some code which can help me identify the problem and how you are using guideBridge. All the stuff you can do with guideBridge library can be achieved without it as well (except submission). The library is generally used when you want any external applications to connect to Form Model.

 

The problem I'm having is that the JSONModel isn't properly linking up with the form controls. When the validation kicks off, it doesn't get the field values because the ID in the JSONModel does not match the ID of the element thus, the value is always null. 

 

As an example:

guideContainer-rootPanel-fragmentPanel-contact-fullLegalName-first___ (the ID of the form field) obtained from ${guideid} in the widget.jsp file.

guideContainer-rootPanel-your-info-contact-contact-fragmentPanel-contact-fullLegalName-first__ (the ID in the JSONModel)
 

Then the other issue is that the failed elements all have the _visible flag set to true where 90% of them are initially hidden. 

Avatar

Level 4

One item that might be of note is that we are using fragments under the root page to define portions of the document.

Avatar

Level 4

roberth55706517 wrote...

One item that might be of note is that we are using fragments under the root page to define portions of the document.

 

Just a thought on this. Is the ID for the element calculated before the fragment is embedded in the master form? In that case, the JSP may not know the path that includes panels built into the master. Or, is the id calculated after the document has been assembled from all of the fragments?