Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-103745

As a fragment developer I can use data-* attributes instead of custom elements to define editable fields

    Details

      Description

      Warning about lfr-editable tags style: we are keeping block style on lfr-editable tags to keep compatibility with fragments using them. However, no extra styling will be added to data-* editables, so they are shown as the fragment developer decided.

      Context

      Our existing editable fields use a custom HTML element named `lfr-editable` with some attributes defining the attribute type and id. This API is valid standard HTML, but it has some caveats:

      • lfr-editable tags need to be replaced with some other arbitrary tag in production. We are currently using divs, but user's may want to use another tag. Moreover, this produces inconsistencies between the view mode (which has a <div>) and the edit mode (which has the original <lfr-editable/> tag).
      • lfr-editable tags require an id attribute to identify editables, which has to be unique within the fragment. But that causes some confusion since in HTML ids must be unique in the whole document.

      The goal of this story is to provide an alternative way to define editable fieldsby using data-* attributes. This method does not require adding extra elements in the production HTML markup.

      Below are the current and the new way of defining editables for each of the supported editable types


      Image Editable

      Current markup:

      <lfr-editable type="image" id="img1">
        <img src="placeholder.jpg" alt="Placeholder">
      </lfr-editable>

      New alternative markup:

      <img
        src="placeholder.jpg"
        alt="Placeholder"
        data-lfr-editable-id="img1"
        data-lfr-editable-type="image"
      >

      Other valid tags: <picture> (if technically feasible)

      Link editable

      Current markup:

      <lfr-editable type="link" id="link1">
        <a href="#placeholder" target="_blank">Go to placeholder</a>
      </lfr-editable>

      New alternative markup:

      <a
        href="#placeholder"
        target="_blank"
        data-lfr-editable-id="link1"
        data-lfr-editable-type="link"
      >
        Go to placeholder
      </a>

      Other valid tags: none

      HTML editable

      Current markup:

      <lfr-editable type="html" id="text1">
        <h1>Placeholder</h1>
      </lfr-editable>

      New alternative markup:

      <article data-lfr-editable-id="text1" data-lfr-editable-type="html">
        <h1>Placeholder</h1>
      </article>

      Other valid tags: any block element

      Text editable

      Current markup:

      <lfr-editable type="text" id="text1">
        Placeholder
      </lfr-editable>

      New alternative markup:

      <p data-lfr-editable-id="text1" data-lfr-editable-type="text">
        Placeholder
      </p>

      Other valid tags: any block or inline element

      Rich text editable

      Current markup:

      <lfr-editable type="rich-text" id="text1">
        Placeholder
      </lfr-editable>

      New alternative markup:

      <p data-lfr-editable-id="text1" data-lfr-editable-type="rich-text">
        Placeholder
      </p>

      Other valid tags: any block element tag

      Acceptance criteria

      • Given fragments developed for Liferay 7.1 or 7.2
      • When they are used in 7.3
      • Then they still work as expected, since using the <lfr-editable> tag is still supported
      • Given a fragment with an editable defined with the new data-* attributes in a valid HTML element for its type
      • When the fragment is added to a page
      • Then the editable value can be set as defined by the type
      • Given a fragment with an editable defined with the new data-* attributes in an invalid HTML element for its type
      • When the fragment developers validates the fragment (using the Fragment Toolkit)
      • Then an error is shown specifying the line of the mistake and the valid tags for the editable type specified
      • Given a fragment with an editable defined with the new data-* attributes in an invalid HTML element for its type
      • When the fragment is created with Fragment Editor
      • Then the editable cannot be saved

      Test Cases

      Test Scenarios Test Strategy Kind of test Is it covered by FrontEnd ? (JS-Unit) Is it covered by BackEnd ? (unit or integration)
      The fragments with <lfr-editable> tag should work as expected Regression Manual Yes Yes (tests continue to work as expected)
      The value of editable field in fragments with data-* attributes should be shown as defined Smoke Manual Yes Yes
      The error message should be shown when import a fragment containing the invalid element via Liferay Fragments Toolkit Sanity Manual No No
       The field should not be editable when the type of element conflict with data-* attributes Sanity Manual  No  Yes

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                david.gutierrez David Gutiérrez Mesa
                Reporter:
                pablo.molina Pablo Molina
                Engineering Assignee:
                Pablo Molina
                Recent user:
                Pablo Molina
                Participants of an Issue:
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Packages

                  Version Package
                  Master