Closed niekraaijmakers closed 3 years ago
I am not certain that the current project should be used to compensate for the absence of Sling Models in "underlying" libraries, modules, packages, or bundles.
if HierarchyNodeExporter
isn't required, the scope of the current project should remain the support of SPA SDK capabilities. We could instead enhance [0]
Agree with above, however this path will take longer to walk. However it is the correct one
Merging #26 (d6c048c) into master (9d7263e) will increase coverage by
6.90%
. The diff coverage is33.33%
.
@@ Coverage Diff @@
## master #26 +/- ##
============================================
+ Coverage 70.98% 77.88% +6.90%
- Complexity 71 89 +18
============================================
Files 7 9 +2
Lines 193 199 +6
Branches 30 30
============================================
+ Hits 137 155 +18
+ Misses 39 27 -12
Partials 17 17
Impacted Files | Coverage Δ | |
---|---|---|
...spa/project/core/internal/impl/RemotePageImpl.java | 0.00% <0.00%> (ø) |
|
.../adobe/aem/spa/project/core/models/RemotePage.java | 0.00% <0.00%> (ø) |
|
...e/aem/spa/project/core/internal/impl/PageImpl.java | 76.08% <66.66%> (+36.55%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update ccd622e...d6c048c. Read the comment docs.
I am not certain that the current project should be used to compensate for the absence of Sling Models in "underlying" libraries, modules, packages, or bundles.
if
HierarchyNodeExporter
isn't required, the scope of the current project should remain the support of SPA SDK capabilities. We could instead enhance [0]
HierarchyNodeExporter turns out not to be required. However having said that, the thing we need to modify here is the page (so we can edit it), not the component for inclusion.
The only (better) alternative is to have the experience fragment editor support mixins or something like that, so you don't have to inherit the resource type cq/experience-fragments/components/xfpage
@gabrielwalt Do you know if there is any plan for ExperienceFragmentPage cq/experience-fragments/components/xfpage
to inherit the Core Page component ?
@gabrielwalt @CezCz @habansal can somebody else review this? Since patrick will be away for a long time
I checked and there is no plan in the near future to update ExperienceFragmentPage cq/experience-fragments/components/xfpage
to inherit the Core Page component.
Until that is done, we shouldn't block SPA users to use XFs with SPA Editor. Hence, +1 to this fix
@niekraaijmakers FYI, Code coverage is failing on this PR.
Failing code coverage check seems un-related to the code added in this PR. It seems to be happening because of the merge master commit - https://github.com/adobe/aem-spa-project-core/pull/26/commits/22eb6d622227530f3c0607ecb1f87ec1ab05c9f6 So, i guess, we can ignore that
Looks like HierarchyNodeExporter is required. Follow up PR - https://github.com/adobe/aem-spa-project-core/pull/35
Description
This is done by adding a resource type that extends cq/experience-fragments/components/xf-page. Since this type does not support core components (it doesn't inherit the core component page), the model's core components functions don't work.
Therefore a JsonSerialze(as=...) is used to prevent errors being thrown in the model.json.
Related Issue
https://github.com/adobe/aem-spa-project-core/issues/25
Motivation and Context
How Has This Been Tested?
I tested this in my implementation project with an experience fragment.
Screenshots (if appropriate):
Types of changes
Checklist: