Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save As Fragment #1433

Open
wants to merge 24 commits into
base: dev
Choose a base branch
from
Open

Save As Fragment #1433

wants to merge 24 commits into from

Conversation

dmaurya929
Copy link
Contributor

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have signed the Adobe Open Source CLA.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes and the overall coverage did not decrease.
  • All unit tests pass on CircleCi.
  • I ran all tests locally and they pass.

Copy link

codecov bot commented Oct 14, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.27%. Comparing base (19da0c7) to head (a855a8f).
Report is 3 commits behind head on dev.

Additional details and impacted files
@@            Coverage Diff            @@
##                dev    #1433   +/-   ##
=========================================
  Coverage     82.27%   82.27%           
  Complexity      923      923           
=========================================
  Files           103      103           
  Lines          2369     2369           
  Branches        321      321           
=========================================
  Hits           1949     1949           
  Misses          257      257           
  Partials        163      163           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@adobe-bot
Copy link

Accessibility Violations Found

Id Impact
focus-order-semantics minor
label-title-only serious
landmark-one-main moderate
region moderate
target-size serious

@adobe-bot
Copy link

Accessibility Violations Found

Id Impact
label-title-only serious
target-size serious

Copy link
Collaborator

@rismehta rismehta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

check comments

@@ -2,4 +2,5 @@
<jcr:root xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0"
jcr:primaryType="nt:unstructured"
jcr:title="Fragment"
fragmentPath=""
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need an empty key here ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need a way to distinguish between a panel and a fragment component. So, we changed the component's cq: template to always include fragmentPath. Otherwise we will have to create new property like fd:viewType to differentiate

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer fd:viewType rather than fragmentPath, since this is not intuitive.

window.CQ.FormsCoreComponents.Utils = window.CQ.FormsCoreComponents.Utils || {};
const DataModel = window.CQ.FormsCoreComponents.Utils.DataModel = window.CQ.FormsCoreComponents.Utils.DataModel || {};

var FORM_CONTAINER_SELECTOR = "[data-cmp-is='adaptiveFormContainer']";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None of this code is going to be changed by core component developers, let's move this code to cq-guides (like we have done for replace / rule editor etc), since this logic is very specific

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, these codes should not require any customization. In that case Data Model code will also required to moved to avoid duplicacy right ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree that the data model code shouldn't be included here. We should keep the codebase clean by only including the relevant components that are customizable or useful for developers

</templateselector>
<fragmentselectcontainer
jcr:primaryType="nt:unstructured"
granite:class="coral-Form-fieldwrapper cmp-adaptiveform-saveasfragment__fragmentselector-container"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need this class, coral-Form-fieldwrapper

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to align with style of other field wrapper in dialog . This field is appended on client side while others are rendered at server.
[1]: https://developer.adobe.com/experience-manager/reference-materials/6-5/coral-ui/coralui3/styles.html#coral-Form

Copy link
Collaborator

@rismehta rismehta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

check comments

@@ -171,4 +174,34 @@

window.CQ.FormsCoreComponents.editorhooks.allowedCompFieldTypes = [];

window.CQ.FormsCoreComponents.editorhooks.getFormContainerProperties = (editablePath) => {
const result = $.ajax({
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use the new fetch syntax here, rather than using $.ajax

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ajax call is made with async: false, used in condition 1 to display DOR action in the editable toolbar. Since fetch is inherently asynchronous, it'll require adding support in the core editor to handle async/await so keeping as it is.

Copy link
Collaborator

@rismehta rismehta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

check comments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants