adobe / adobe/aem-core-wcm-components

[Form] Avoid Utils.getURL(), instead use Linkchecker/ResourceResolverMapTransformer/...

Open
#94 10 comments 0 reactions 0 assignees View on GitHub
enhancement good first issue
Dominant language
Java
Stars
795
Forks
775
Avg merge
3d 22h
Merged PRs (30d)
8

Description

When rendering the form container component, when determining the form action, the following method is called:
`this.action = Utils.getURL(request, currentPage);`
https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/d4a9c2c7785f5d50e91dd2ebe145ace4a0bb7491/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/models/v1/form/ContainerImpl.java#L123

I am not happy with this approach:
1. In case the user enters "test" as a sling:vanityUrl, this value will be used literally; Meaning the tag will be `` which will of course go wrong (there is probably a lot more logic involved, than just taking the value and putting it in an HTML attribute)
2. The form container component (and other components) should not have the responsibility of rendering these mapped/transformed urls, but instead the responsibility should be within the frameworks we already have available (linkchecker, resourceresolvermaptransformer in acs commons, resourceResolver.map() which takes sling:vanityUrls into account)

https://cwiki.apache.org/confluence/display/SLING/Flexible+Resource+Resolution#FlexibleResourceResolution-CurrentStatus

Contributor guide

Open the contributing guide

Research direction

Start in bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/models/v1/form/ContainerImpl.java around line 123 and review how the form action is obtained. Read the linked Sling flexible resource resolution guidance and compare the available Linkchecker, ResourceResolverMapTransformer, and resourceResolver.map() approaches. Done means the form container no longer directly relies on Utils.getURL and handles vanity URLs through the chosen framework mechanism.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.