AEM Forms (OSGI forms add-on on-premisies ) Core component "Dispaly Pattern" propery missing in Form core component dialogue

[varaande]

Hi Team

We are currently developing a custom Adaptive Form component using Core Forms Components. However, we are unable to see the "Display Pattern" option, which is available in Forms Foundation (Legacy) Components.

Problem:
In AEM Forms (OSGi forms add-on on-premises), when using Adaptive Forms Core Components, the Display Pattern property is missing in the Core Component dialog.

Regards

Vara

[rismehta]

@varaandeIn Core Components, we use displayFormat instead of patterns for better performance. This is supported for date picker and number input components, as documented here:

https://github.com/adobe/aem-core-forms-components/tree/master/ui.af.apps/src/main/content/jcr_root/...

https://github.com/adobe/aem-core-forms-components/tree/master/ui.af.apps/src/main/content/jcr_root/...

Here are a few examples where this has already been used: https://github.com/search?q=repo%3Aadobe%2Faem-core-forms-components+%22displayFormat%22+language%3A...

Could you elaborate on your use case if you’re looking to apply this to the text input component?

You can also report such issues here: https://github.com/adobe/aem-core-forms-components/issues

[varaande]

Hi @rismehta 

I hope you're doing well. I am currently facing an issue with the Number Input component and its displayFormat functionality.

Use Case 1:
I’m trying to apply a display pattern/format (e.g., 00-001-1111), but the number input is displaying the value as 11111 instead of following the intended display format. Ideally, if the input includes preceding zeros, the display pattern should be applied in the same way as the Foundation or Legacy components handle text input fields.

Use Case 2:
I need to apply a display pattern/format for specific inputs, such as SSN (xxx-xx-xxxx), EIN (xx-xxxxxxx), or PTN numbers, which may contain characters but should still follow the display pattern.

It seems that the display pattern logic in the Number Input component is tied to the client library code, which is built at the component level.

Use Case 3:
We have a similar requirement where we need to apply the display format to text input fields since the inputs might contain characters, and the pattern needs to be applied accordingly.
(Ex : Preparer Taxpayer Identification Number (PTIN) : 1234-56P89)

How can we add a display format or pattern to an input text field? We copied the cq:dialog node for the display format, but it is not working since it is linked to the client library code. What is the best way to reuse the display format logic for input text?
How can we add a display format or pattern to an input text field? We copied the cq:dialog node for the display format, but it is not working since it is linked to the client library code. What is the best way to reuse the display format logic for input text?

I appreciate your assistance in resolving this.

[rismehta]

Thanks, @varaande , for sharing the use case. I've logged an enhancement ticket to support these common scenarios natively in the product without requiring customization.

For now, please use the format option in the Visual Rule Editor for this use case. I've attached a screenshot below. This feature is behind a feature toggle—if you're on Cloud, please reach out to support to enable it. For AEM 6.5, you can use the toggle FT_FORMS-13193.

[VARA_PRASADA_RAOAN2]

@rismehta 

Thank you very much. I able to see the "format" option but Display pattern not applied if we give as ###-##-#### or text {999-99-9999) it display same instead of applying the pattern to given value . Please help how to apply the SSN Display pattern as xxx-xx-xxxx .

One more question, using core component how populate dropdown to apply the pattern automatically same as foundation component (refer below screenshots)

[rishim22446870]

This feature is not yet supported in core components for text input, so the dropdown will not appear. Could you provide the customer name to help prioritize this issue? Alternatively, you can log a feature request support case through the support channel.

For a custom solution, you can refer to the following example:

1.Create a custom function to mask the input, similar to this:
https://github.com/adobe/aem-core-forms-components/blob/4c6f9b44c0641d372e4285c73e6dcd2413eb19ce/it/...

2.Use the custom function in the format value via the Visual Rule Editor: https://github.com/adobe/aem-core-forms-components/blob/4c6f9b44c0641d372e4285c73e6dcd2413eb19ce/it/...

[varaande]

@rishim22446870 

Thank you very much.
Customer Name :Internal Revenue Service(IRS.gov)

Regards

Vara

[varaande]

@rismehta 
Kindly advise  us alernative options binding the XDP to JSON schema for core component development Since AEM Forms Designer doesn't provide direct out-of-the-box functionality for binding JSON schemas to XDP forms.

Currently  Forms creating using xml schema then xdp is binding with xml schema but core component approach additon to json schema over complicated system . Please advise recommeded approach.

[rismehta]

@varaande 

Why are you using XDP-based forms? Are you reusing specific rules from the XDP form, or is it primarily for the Document of Record (DoR)?

If it's for DoR, you might consider using a JSON Schema-based form with the Auto Document of Record feature instead.

We generally do not recommend XDP-based forms in core components, as they are not optimized for web performance.

[VARA_PRASADA_RAOAN2]

@rismehta 
Thank you. Currently we are not using rules associated with XDP.

Here is our use case:
Current State: PDF (XDP based) forms manually downloading public website (irs.gov) then filling manually sending via postal service to process the form.

Future State: Current State + Same forms digitizing or convert to digital digits using AEM Forms add-on package, But DOR or PDF must match with Manual PDF form for this using XDP for DOR. 

Current Form development Process:
Step1: Creating adaptive form xml schema based manual pdf (xdp)
Step2: Create AF using XML Schema
Step3: Binding XDP with XML schema 
Step 4: Submit Form PDF (if form any attachment merge into pdf) external system to process along json or xml file based external system supported form either xml or Json 

For core component development, we though we replace XML Schema with JSON schema but AEM Designer not Json binding option does not support XDP)

Please share recommended approach core component development to get the AEM forms production maximum benefits (we are using AEM product only pure forms project no sites no DMAF Assets)

[rismehta]

@VARA_PRASADA_RAOAN2

Thank you for providing detailed information about the use case. You can achieve this by using a JSON schema in the following manner:

New Form Development Process Using Core Components:

• Create an XML schema-based manual PDF (XDP).
• Develop an AF (Adaptive Form) using the JSON Schema.
• Bind the XDP to the XML schema.
• Submit the form (including any attachments merged into the PDF) to an external system for processing in JSON format
  
  

Key Points:

• It’s necessary to maintain an XML schema corresponding to the JSON schema to ensure proper binding with the XDP.
• We do not recommend using XML schema for web-based forms due to optimization concerns for web performance.

[varaande]

@rismehta 

Thank you! The main reason for choosing the AF Core Component approach is performance. Tax forms are complex, often containing 200-500 fields without intricate logic. While authoring and rendering for end users, especially with multiple signatures, we face significant performance issues due to XML Schema-based forms.

Here are our key questions:

1. Will adding additional JSON impact performance negatively, or will the Core Component approach still improve it?

2. We plan to maintain consistent field names between JSON Schema and XML Schema (XDP binding). Do you foresee any binding challenges?

3. You mentioned performance concerns with XML Schema-based web forms. Given our existing performance issues, what optimizations would you recommend?

Do you believe the Core Component approach will enhance performance for our use case?

[rismehta]

@varaande Apologies for the delay.

There may still be performance issues when handling 500 fields, even with core components in the form editor. To mitigate these issues, it's recommended to use fragments, as outlined in the best practices documentation.

Although core components are generally more performant due to their lack of reliance on XML, in your case, you also need to leverage the existing XML-based backend infrastructure you've already built. Therefore, I recommend continuing with foundation components and implementing lazy loading and fragments to improve performance during authoring and form rendering.