[MGNLFE-15] SPA developer can easily get activation state Created: 05/Nov/19  Updated: 27/Apr/20  Resolved: 17/Jan/20

Status: Closed
Project: Magnolia Frontend Helpers
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0

Type: Improvement Priority: Neutral
Reporter: Christopher Zimmermann Assignee: Sang Ngo Huu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 2.25d
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Documentation update required:
Yes
Date of First Response:
Epic Link: SPA Editor
Sprint: SPA Editor 14
Story Points: 5

 Description   

User Story: As a SPA developer, I can easily get the activation state of components so that content authors will see the activation state of components as they do with FTL based pages.

Notes:

Activation state is normally provided in the HTML comments which the page editor uses to generate the green bars. So a developer would need to supply it for those.

Probably the generic Magnolia library should have a conveneint method to calculate the activation state based on the content. 

In the end, ideally the typical SPA developer shouldnt have to think about it, they should just use our best practice library - and the HTML comments will be generated with everything they need, including the activation state.

Technical Note:

There is already a "mgnl:activationStatus" property - but it does not hold the actual activation status as we need it. For example a yellow item has a value of 'true'.



 Comments   
Comment by Mikaël Geljić [ 11/Nov/19 ]

Documenting two possibilities:

1. secondary templateDefinition endpoint, as outlined on PR #131

Step 3:

  • support activation status back
  • accept again a node-path as optional input, in order to embed activation status for it and its areas/components
  • then we would define how the JSON response should differ/evolve from above to figure out where to add metadata properly, for example:
{
  "definition": { // same as above
    "@id": "foo:pages/my-spa",
    "renderType": ...,
    "dialog": "foo:pages/my-spa",
    "areas": [
      { ... }
    ]
  },
  "contentMetadata": { // for the lack of a better name; also reusing deliveryEndpoint format, so data can be mapped or merged if needed 
    "@path": "/foo",
    "@publicationStatus": "modified",
    "0": {
      "@publicationStatus": "published"
    },
    "00": { ... },
    "@nodes": [ "0", "00" ]
  }
}

2. provide utility to compute it from the client side, if delivery includes system-properties mgnl:lastModified and mgnl:lastActivated.

Comment by Christopher Zimmermann [ 16/Dec/19 ]

This feature is important because without it the author will not have any indication of which components have been modified since the last time the page was published. Essentially a standard Magnolia feature will be broken when working with a SPA template.

Especially any author who has used the pages app will be confused. All of the components will look like they are published, they will not show a yellow or red status symbol to indicate that they are new or that they have been edited.

An author will see that the page as a whole has been edited in the browser - but if they open the page - then they won't see which component has been edited. 

Comment by Christopher Zimmermann [ 18/Dec/19 ]

From a "developer experience" perspective - I prefer option 2. No extra rest call. 

Comment by Sang Ngo Huu [ 15/Jan/20 ]

quote from mgeljic on Slack channel:

re: mgnl:activationStatus JCR prop:

  • mostly spares date comparison for unpublished nodes => impl detail 
  • value (through Activatable#isActivated) is never used directly for UI display, nor in templating => all goes through proper Activatable#getActivationStatus
  • would suggest to use that too for REST delivery:
    e.g. compute a new special property @activationStatus (or with newer "publishing"-based name)
    if possible only enable this special property from author instance
Generated at Mon Feb 12 05:43:24 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.