(Using notes from @andrerom to try to create an overall epic for v2 requirements)

v2 Revamp Requirements Epic

Scope

This Epic defines requirements and approaches for further activities moving towards eZ Platform 2.x, focused on DX in four areas:

1. Quality Control (BDD, Specification, Documentation)
2. Performance by Design (REST API optimizations)
3. Modern Architecture (Symfony 3.x, Future-Proof UI)
4. Development Process Awesomeness (Extending, Pipeline, Tooling, SDKs)

Stories under this Epic will fall under one of the above four categories (QC, PbD, MA, DPA), and may spin off into Epics of their own as we iterate.

This Epic will be "done" when there is a Markdown document in the specs repo defining overall project requirements and linking to their associated issues.

Requirements for v2 Solution:

Non-functional

• 2018-class browsers, implying support for
  • ES2016 or better
  • HTML5.1 or better
  • ...
• PHP 7.0 (as of Debian 9 available in all linux distros we support)

Functional

Compared to 1.7.0 LTS, 2.x should be:

• Minimum 2x faster in Production and 3x in Development
• Minimum 3x faster to extend, in common use cases like:
  • UI Menu Items with Symfony own modules views
  • Field Types
  • ...
• Have higher quality (less known defects). Common scenarios should "just work.":
  • Multi Site
  • Multi Language
  • ...
• Each feature should contain raw documentation from Dev and Spec from PM, so external testers and documentation team have enough content to make user documentation and blogs.

This issue may be used for discussion below.

As we transition to a Modern Architecture, we need to explore ways in which we can still use some modules from YUI during the transition.

The deliverable for this Spike will be an estimated Story or Stories, to include: "As a Developer, I want a roadmap from v1/YUI to v2/TBD, so that I can contribute to v2 in an iterative transition", related to Epic https://jira.ez.no/browse/EZP-26866

The timebox for this Spike is up to X hours (X.x days). (Final timebox number TBD w/Engineer(s).)

Postponed pending Engineer availability.

This Spike is authorization to explore and pursue the proposal given here: https://github.com/ezsystems/PlatformUIBundle/blob/poc_subitem_udw_sf_app/docs/subitem-udw-in-sf-app.md

Demo and Public Repo pending (see comments)

Further reading: http://www.omh.cc/blog/2017/jan/13/why-ez-should-adopt-emberjs/

Request For Comment

Further clarification:

• Let's determine whether there is community interest in developing an additional Admin UI solution, without eZ's direct involvement, for those that wish to live and work in the world of Ember.
• Also, let's brainstorm not what Ember can do for eZ developers, but what eZ can do for Ember developers. (See comments)

REQUIREMENTS: https://github.com/ezsystems/specs/blob/v2-prototype-symfony3hybrid/eZ%20Platform/Admin%20UI/REQUIREMENTS.md

USE_CASE: https://github.com/ezsystems/specs/blob/v2-prototype-symfony3hybrid/eZ%20Platform/Admin%20UI/USE_CASE.md

Defining requirements for improvements to the Docker Developer Experience with eZ Platform.

Next step, after requirements are defined: R&D: POC/Prototyping

After R&D:POC/Prototyping, Specifications may be defined here in ezsystems/specs as MarkDown files.

Request For Comment

Questions a prototype could help answer:

• What would eZ Platform's Admin UI look like under the hood if it used Vue.js instead of YUI?
• What would a Vue.js developer want/need to have a great DX building things with eZ Platform?

Further clarification:

Let's determine whether there is community interest in developing an additional Admin UI solution, without eZ's direct involvement, for those that wish to live and work in the world of Vue.js.
Also, let's brainstorm not what Vue can do for eZ developers, but what eZ can do for Vue developers.

Hi,

I like the idea of webcomponents. My hope is that with the right set of ez platform webcomponents. We can customize, extend and replicate the admin more quickly.

The new admin should be webcomponents based!

Cheers...

Defining requirements for improvements to the REST API Developer Experience with eZ Platform.

Next step, after requirements are defined: R&D: POC/Prototyping ( Spike: https://github.com/ezsystems/ezplatform/issues/160 )

After R&D:POC/Prototyping, Specifications may be defined here in ezsystems/specs as MarkDown files.

As a developer I want to rely on a unique, compact solution to expose Field Type (CRUD: create read update delete) whether it is to be used in :

• Platform UI
• a Twig / eZ Platform-based website
• a remote website
• an app using REST API (e.g. React Native)

This solution will most certainly be part of the larger solution(s), but is isolated here to focus on its particular area of interest.

Pending further discussion with PM/Engineering

Awaiting discussion with PM/Engineering

Awaiting discussion with PM/Engineering

Epic: https://jira.ez.no/browse/EZP-26519

Contains, but potentially not limited to improvements on:

• Languages (goal: avoid having to use translation helpers)
  • If language is not provided take SiteAccess languages into account before falling back to main language, all over
  • Only load one language, threat language params as priority like now on search
  • Reflect this on ContentInfo name as well
• Multi get support for all/most domain objects for optimized lookups (should also take into account language api changes from above)
  • Need to define how these should work when a item is not existing, maybe methods let user code specify if exception should be thrown or if value should be missing (default) for optimal user code
• Native Location drafts (goal: get rid of preview issues)
  • (however needs to make sure queries using data from this draft works as expected, with workspaces children should be query able for instance)
• Visibility (goal: move to permissions to get rid of boilerplate code)
• Site knowledge (goal: somehow natively take care about path prefixes and such)
  • Open question is how to avoid having to do with and withouth lookups for UrlAlias lookups.
• Abstract: Domain Types (Like Object Wrapper, allow more logic to be moved to type instance, aka the content, as opposed to templates, examples: Asset, Site,..)
• For further use see Kaliop ObjectWrapper, NetGen SiteAPI, ..., if we add API caching, and/or add a form of lazy loading we can enrich the model with capabilities such as:
  • Adding Content on Location
  • Introduce LocationInfo for meta data bases for locations
  • Add LocationInfo for main location onContentInfo
  • Introduce ContentTypeInfo for light meta data info on content type
  • Add ContentTypeInfo on ContentInfo
  • Add LocationInfo to represent parent on Location

RFC

To be aware of the coming features, I would like to be able to ask questions and put comment on specifications before they become final, to be sure, I understand the topics and the impacts on the product (and therefore on my Precious Documentation 💎 ).

Do you think we can use the Pull Request system to achieve that ?

It's linked to the #1 issue, I think.

Upgrading eZ Platform and EE to use Symfony 3.x

• Identify the best approach for routing, extending, etc.
• Enumerate all extension points that we have and work through iterations to simplify them:
  • Custom link in Navigation Hub + what we used to call "Custom module" in legacy rendered server side
  • Field view and Field Edit View for custom field types
  • Field Types
  • Menu Items
  • Action Buttons
  • custom sub-item view (it's today possible, and well done by Damien, unfortunately it's in YUI). This should be possible using Symfony.
  • custom sub-tab in the content-view (example: I created a custom content type Product with new field types for stock, I want a new tab in View that will give me access to custom feature about stock management....
  • custom tab in the admin panel
  • custom dashboard widget
  • Studio-specific extension points (there are a few there to be listed)

TODO: Need to more clearly identify what is expected behavior in 2.x, and more importantly where it differs from 1.x. If there are missing features in 1.x that are expected to be fixed as part of this we need to get those to surface as well. Even those not planned immediately would be great to track so Developers are aware during refactoring where a given component is intended to go; it will guide how the code is made and, in some cases, it will be low hanging fruit during their work.

Perhaps you've noticed that this repository is empty... we know! We are getting things set up to share requirements and specifications here "in the wild" on GitHub in this repo, so you'll see lots of action here soon.