Details

    • Epic Name:
      RichText editing

      Description

      Current XMLtext field type uses the old xmltext ezxml format, a better approach in the future would be to use and update the Document component so it handles the internal format instead (docbook).

      Format

      The Field Type may expose several formats like intended with eZ Document Component, but for WYSIWYG editors and web use there is a need to have a xhtml5 like format that has all the capabilities of ezxml or even more.

      A xhtml5 wysiwyg format could be based on ezxml but with some changes:

      • Tag names should be changed to names in html5, most are easy, custom tag is not.
      • Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
      • Attribute names should be aligned with html5 (map custom attribute to -data-?)
      • Valid parent and child tags might need some minor adjustments, table in paragraphs for instance.
      • As for section tags, that can be mapped to the html5 section tag, and this can be visually hinted by the editor in needed: http://www.tinymce.com/tryit/html5_formats.php

      For Legacy Database there could be a converter that transforms the format to ezxml, if eZ Document Component is used then it needs some updates for minor changes done to the format in 4.1.

        Issue Links

          Issues in Epic

            Activity

            Show
            Dominika Kurek added a comment - Documented in User Guide: https://doc.ez.no/display/USER/Creating+content#Creatingcontent-EditingRichTextFields
            Hide
            André Rømcke added a comment -

            Comments above are out of date, look to #EZP-21136 and #EZP-21191 for what we ended up with after prototyping.

            Show
            André Rømcke added a comment - Comments above are out of date, look to # EZP-21136 and # EZP-21191 for what we ended up with after prototyping.
            Hide
            André Rømcke added a comment - - edited

            Never talked about changing format in Legacy storage, as for internal format that is an other discussion which Patrick did a design and requriment spec on:
            https://github.com/ezsystems/ezp-next/tree/Specification/eZXML5/doc/specifications/api/field_type/ezxmltext

            Re cap: Proposes to use Zeta Document component in the background with Docbook as internal format, convert to legacy ezxml in Legacy fieldtype Converter and convert to many different formats in the Public API (ezxml, "ezxml5", reST, wiki, markdown, xhtml, html5, ..).
            The main pieces of work that needs to be done is to update the ezxml support as it lacks features added in 4.1, and on top of that formats it does not already support (first and formost: "ezxml5").

            Show
            André Rømcke added a comment - - edited Never talked about changing format in Legacy storage, as for internal format that is an other discussion which Patrick did a design and requriment spec on: https://github.com/ezsystems/ezp-next/tree/Specification/eZXML5/doc/specifications/api/field_type/ezxmltext Re cap: Proposes to use Zeta Document component in the background with Docbook as internal format, convert to legacy ezxml in Legacy fieldtype Converter and convert to many different formats in the Public API (ezxml, "ezxml5", reST, wiki, markdown, xhtml, html5, ..). The main pieces of work that needs to be done is to update the ezxml support as it lacks features added in 4.1, and on top of that formats it does not already support (first and formost: "ezxml5").
            Hide
            Christian Bacher (Inactive) added a comment - - edited

            General Question: is changing the format in storage necessary?
            The conversions can be done anywhere else even above the public api.
            And there will be other conversions not necessarily to html5 for different applications.
            This leads more to a generic xml format which we already have (kind of).

            Show
            Christian Bacher (Inactive) added a comment - - edited General Question: is changing the format in storage necessary? The conversions can be done anywhere else even above the public api. And there will be other conversions not necessarily to html5 for different applications. This leads more to a generic xml format which we already have (kind of).
            Hide
            André Rømcke added a comment - - edited

            Possible requirements:

            • Polyglot Markup, aka both valid html5 & xml
            • Easily transformable using for instance xslt to transform to and from old and new format in Legacy converter.

            Reasoning for changing the format:

            • Writing OE 5.x was 1 year effort and still counting in terms of Support, if we can cut this down considerably by aligning our self with the format all future wysiwyg editors support: (x)html5, that will be worth it in terms of effort needed in the future on this FiledType.
            • Make it possible to more easily parse and deal with ezxml output in for instance REST clients
            Show
            André Rømcke added a comment - - edited Possible requirements: Polyglot Markup, aka both valid html5 & xml Easily transformable using for instance xslt to transform to and from old and new format in Legacy converter. Reasoning for changing the format: Writing OE 5.x was 1 year effort and still counting in terms of Support, if we can cut this down considerably by aligning our self with the format all future wysiwyg editors support: (x)html5, that will be worth it in terms of effort needed in the future on this FiledType. Make it possible to more easily parse and deal with ezxml output in for instance REST clients

              People

              • Assignee:
                Unassigned
                Reporter:
                André Rømcke
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: