Details

    • Type: Epic Epic
    • Status: Closed
    • Priority: High High
    • Resolution: Obsolete
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Epic Name:
      [v2][Prototype] Content Field Edit

      Description

      Requirements are iterating here:

      https://github.com/ezsystems/requirements/pull/10

        Issues in Epic

          Activity

          Hide
          André Rømcke added a comment - - edited

          Possible followups?

          • Spike on on seeing if we can do the mapping to symfony forms automatically once we use symfony validation instead
          • Spike to see if we can have meta info on html5/js type info + validation data available for use in: Twig, JS (e.g. React, ..) and Non Web (e.g. React Native, Swift, ..) use cases
            • Aim to cover things that are understood by the misc technologies: textline, textblock, integer, float, date, datetime, ... (could even be including Rating for instance, which is a int type on the content field value, specifically it is a checkbox for UI so we would need to serialize info for that)

          Otherwise: possible other spikes on looking into simplifying developing and maintaining field types even more, like making it more optional to specify info to Solr/Elastic (ideally also use type info mentioned above for validation to give solr info on the type of each field more natively).

          Side: Once we introduce Improved storage engine we plan to get rid of FieldType converters and just serialize to json, bug this is not a topic to handle in this epic.

          Show
          André Rømcke added a comment - - edited Possible followups? Spike on on seeing if we can do the mapping to symfony forms automatically once we use symfony validation instead Spike to see if we can have meta info on html5/js type info + validation data available for use in: Twig, JS (e.g. React, ..) and Non Web (e.g. React Native, Swift, ..) use cases Aim to cover things that are understood by the misc technologies: textline, textblock, integer, float, date, datetime, ... (could even be including Rating for instance, which is a int type on the content field value, specifically it is a checkbox for UI so we would need to serialize info for that) Otherwise: possible other spikes on looking into simplifying developing and maintaining field types even more, like making it more optional to specify info to Solr/Elastic (ideally also use type info mentioned above for validation to give solr info on the type of each field more natively) . Side: Once we introduce Improved storage engine we plan to get rid of FieldType converters and just serialize to json, bug this is not a topic to handle in this epic.
          Hide
          Bertrand Dunogier added a comment -

          Spike on on seeing if we can do the mapping to symfony forms automatically once we use symfony validation instead

          Mapping isn't only about validation. Validation mapping is actually automatic. Each field (definition) will be validated with the FieldType's validation method. Changing FieldTypes to use Symfony validation won't allow us to remove anything for the time being.

          Removing form mappers would require that we can generate the fieldtype forms (value and definition) from the FieldType itself: which properties (form fields), how they're named, what their respective constraints are.

          Otherwise: possible other spikes on looking into simplifying developing and maintaining field types even more, like making it more optional to specify info to Solr/Elastic (ideally also use type info mentioned above for validation to give solr info on the type of each field more natively).

          Feel free to prioritize that on your side, but I don't think it belongs in this epic.

          Show
          Bertrand Dunogier added a comment - Spike on on seeing if we can do the mapping to symfony forms automatically once we use symfony validation instead Mapping isn't only about validation. Validation mapping is actually automatic. Each field (definition) will be validated with the FieldType's validation method. Changing FieldTypes to use Symfony validation won't allow us to remove anything for the time being. Removing form mappers would require that we can generate the fieldtype forms (value and definition) from the FieldType itself: which properties (form fields), how they're named, what their respective constraints are. Otherwise: possible other spikes on looking into simplifying developing and maintaining field types even more, like making it more optional to specify info to Solr/Elastic (ideally also use type info mentioned above for validation to give solr info on the type of each field more natively). Feel free to prioritize that on your side, but I don't think it belongs in this epic.
          Hide
          Sylvain Guittard added a comment -

          Closing because the prototype time has passed

          Show
          Sylvain Guittard added a comment - Closing because the prototype time has passed

            People

            • Assignee:
              Unassigned
              Reporter:
              Roland Benedetti
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: