You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The purpose of this document is to provide a rough big picture to help us prioritize the many complex tasks that need to be achieved for the development of the Component Engine.
This is a living document and everything in here is open for discussion.
The overall mission (a.k.a "What is the Component Engine?")
The Component Engine provides a language that is explicitly designed to express the rendering function of presentational components. This language contains the bare minimum of constructs to allow for expression of rendered HTML code as a function of a component interface, a rich type system to express that interface and only the most simple calculations. These limitations exist to avoid the creation of components that attract logic and to push for the creation of a rich presentation model (as in PackageFactory.AtomicFusion.PresentationObjects).
"Component Engine" as a name was chosen in contrast to the generic term "Template Engine". This is, because the Component Engine drives the use of "Components" rather than "Templates". This can be understood as a working title. The final name (especially that of the language) is still to be discussed.
The most important goal for the Component Engine is to allow for the creation of truly platform- and language-independant presentational components that can be used anywhere, be it client or server (no matter the framework, no matter the platform).
The ecosystem
The support for a multitude of host languages and platforms, as well as the need for tooling integration requires the Component Engine to be a complete language ecosystem. All design and development efforts must not only keep that ecosystem in mind but look at it as the actual product.
Core
As of right now, in the early stages of development, there is only one source code repository to develop the Component Engine. You may think of this repository as an incubator for various concepts that may later be externalized.
Some concepts however will always continue to live in this repository. Those are the "Core" concepts.
Component Engine Language
The Component Engine Language is roughly defined through its AST (Abstract Syntax Tree). As of right now, the AST is modeled in PHP. In the long run, the AST should get a language-independent schema definition. The language should also have an EBNF representation (This is important for future tooling support).
This repository should provide lots of example cases (in the form of BDD-tests written in Gherkin), so that target platforms can verify their parser implementations by using a centralized, official set of tests.
The Component Engine includes a static, manifest and nominal type system to aid with transpilation towards several target languages and to enable static verification of some correctness criteria.
There appears to be no formal language to describe type systems (or is there?). This repository should therefore provide a set of Gherkin-Tests to cover some major questions like:
What built-in types ought to be there?
What user-defined type constructs ought to be there?
In what way are types compatible to each other?
Given the types of all variables, what is the type of the result of an expression?
This includes an idea of what modules are and how to load them. Beyond a (somewhat-)formal definition of the type system, this repository should also provide a set of Gherkin-Tests to test for correct and incorrect program examples.
From the formal definition of the Component Engine language arise the faculties for developer tooling. This is a prime concern for the Component Engine, because it is supposed to provide a way to express components that transcends the limitations of platforms and languages. It is paramount that developers can use the Component Engine with the same tooling assistance they're used to from other languages.
LSP Server
The Language Server Protocol (LSP) is an open, JSON-RPC-based protocol to enable the independent provision of language-specific features like code completion, syntax highlighting or type checking for many IDEs.
Without an LSP server, the Component Engine language can be essentially considered invisible to the larger development community.
It'll likely be necessary to expand Host language support for the Component Engine to at least one other language to make the implementation of an LSP server feasible. It is probably not a good idea to implement a PHP-based server.
A potential candidate for an LSP SDK to implement the LSP for the Component Engine may be "Langium": https://langium.org/
IDE Plugins
It should be a core concern for the Component Engine to provide plugins for the most common IDEs and Code Editors in its (projected) ecosystem. For starters, there should be plugins for:
The Component Engine is designed to work together with a multitude of platforms and languages, allowing for a universal way to express presentational components and allow them to be easily exchanged between projects.
Currently, it is planned for the Component Engine to have core support for PHP and ECMAScript (+TypeScript). Other languages shall be part of a third-party plugin system.
A host language can implement several patterns, tools or libraries to offer support for the Component Engine, like:
Parser: The ability to transform Component Engine language source code into a host-language-specific internal representation of the standardized Component Engine language AST
TypeChecker and/or Linter: Provision of platform-specific CLI tooling
Transpiler: The (preferred) way of creating platform- or language-specific executable code from Component Engine language source code
Runtime: A way to execute Component Engine language source code directly
Each of the listed concepts may or may not live in their own isolated package.
Phase Model for Implementation
There is a need for a strategic approach to handle the sheer amount of concepts that need to be implemented.
This phase model is supposed to accomplish two things:
Prioritize implementation tasks in a practical manner
Enable early use of the Component Engine to establish a fail-fast feedback loop
Phase I - The PHPantom Menace
This is the phase we're currently in. Everything happens in the core repository and everything is developed for the PHP platform.
At the end of this phase, language definition, type system, parser and transpiler for PHP should be stable.
This phase also covers a framework integration for Flow Framework and Neos CMS, enabling the Component Engine to be used in the context of website- and web application-development.
Phase II - Attack of the Client Side
In this second phase, the stable parts from Phase I are to be split up into separate packages. There is to be one package for the PHP parser, the PHP transpiler and so forth until pretty much only the core language definition remains in this repository.
In parallel, this phase should establish first steps into client-side rendering support. As of right now, it is fair to say, that a framework integration for React would be the way to go.
Phase III - Revenge of the Tools
At the beginning of the third phase, the Component Engine language should be stable enough to approach tooling support.
This would also be the time to reach out and try new things, broaden host language support, figure out what can be done with the Component Engine.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The purpose of this document is to provide a rough big picture to help us prioritize the many complex tasks that need to be achieved for the development of the Component Engine.
This is a living document and everything in here is open for discussion.
(For collaboration on the drawings see: https://excalidraw.com/#room=0fc1201079a9f8e8313d,rd3YaFKqxBhYYU_KvSD1Sg)
The overall mission (a.k.a "What is the Component Engine?")
The Component Engine provides a language that is explicitly designed to express the rendering function of presentational components. This language contains the bare minimum of constructs to allow for expression of rendered HTML code as a function of a component interface, a rich type system to express that interface and only the most simple calculations. These limitations exist to avoid the creation of components that attract logic and to push for the creation of a rich presentation model (as in PackageFactory.AtomicFusion.PresentationObjects).
"Component Engine" as a name was chosen in contrast to the generic term "Template Engine". This is, because the Component Engine drives the use of "Components" rather than "Templates". This can be understood as a working title. The final name (especially that of the language) is still to be discussed.
The most important goal for the Component Engine is to allow for the creation of truly platform- and language-independant presentational components that can be used anywhere, be it client or server (no matter the framework, no matter the platform).
The ecosystem
The support for a multitude of host languages and platforms, as well as the need for tooling integration requires the Component Engine to be a complete language ecosystem. All design and development efforts must not only keep that ecosystem in mind but look at it as the actual product.
Core
As of right now, in the early stages of development, there is only one source code repository to develop the Component Engine. You may think of this repository as an incubator for various concepts that may later be externalized.
Some concepts however will always continue to live in this repository. Those are the "Core" concepts.
Component Engine Language
The Component Engine Language is roughly defined through its AST (Abstract Syntax Tree). As of right now, the AST is modeled in PHP. In the long run, the AST should get a language-independent schema definition. The language should also have an EBNF representation (This is important for future tooling support).
This repository should provide lots of example cases (in the form of BDD-tests written in Gherkin), so that target platforms can verify their parser implementations by using a centralized, official set of tests.
Releveant issues/prs:
#20
Component Engine Type System
The Component Engine includes a static, manifest and nominal type system to aid with transpilation towards several target languages and to enable static verification of some correctness criteria.
There appears to be no formal language to describe type systems (or is there?). This repository should therefore provide a set of Gherkin-Tests to cover some major questions like:
This includes an idea of what modules are and how to load them. Beyond a (somewhat-)formal definition of the type system, this repository should also provide a set of Gherkin-Tests to test for correct and incorrect program examples.
Releveant issues/prs:
#23
Tooling
From the formal definition of the Component Engine language arise the faculties for developer tooling. This is a prime concern for the Component Engine, because it is supposed to provide a way to express components that transcends the limitations of platforms and languages. It is paramount that developers can use the Component Engine with the same tooling assistance they're used to from other languages.
LSP Server
The Language Server Protocol (LSP) is an open, JSON-RPC-based protocol to enable the independent provision of language-specific features like code completion, syntax highlighting or type checking for many IDEs.
Plenty of languages have LSP server implementations (see: https://microsoft.github.io/language-server-protocol/implementors/servers/). Plenty of IDEs and Code Editors have LSP support (see: https://microsoft.github.io/language-server-protocol/implementors/tools/).
Without an LSP server, the Component Engine language can be essentially considered invisible to the larger development community.
It'll likely be necessary to expand Host language support for the Component Engine to at least one other language to make the implementation of an LSP server feasible. It is probably not a good idea to implement a PHP-based server.
A potential candidate for an LSP SDK to implement the LSP for the Component Engine may be "Langium": https://langium.org/
IDE Plugins
It should be a core concern for the Component Engine to provide plugins for the most common IDEs and Code Editors in its (projected) ecosystem. For starters, there should be plugins for:
Host Language
The Component Engine is designed to work together with a multitude of platforms and languages, allowing for a universal way to express presentational components and allow them to be easily exchanged between projects.
Currently, it is planned for the Component Engine to have core support for PHP and ECMAScript (+TypeScript). Other languages shall be part of a third-party plugin system.
A host language can implement several patterns, tools or libraries to offer support for the Component Engine, like:
Each of the listed concepts may or may not live in their own isolated package.
Phase Model for Implementation
There is a need for a strategic approach to handle the sheer amount of concepts that need to be implemented.
This phase model is supposed to accomplish two things:
Phase I - The PHPantom Menace
This is the phase we're currently in. Everything happens in the core repository and everything is developed for the PHP platform.
At the end of this phase, language definition, type system, parser and transpiler for PHP should be stable.
This phase also covers a framework integration for Flow Framework and Neos CMS, enabling the Component Engine to be used in the context of website- and web application-development.
Phase II - Attack of the Client Side
In this second phase, the stable parts from Phase I are to be split up into separate packages. There is to be one package for the PHP parser, the PHP transpiler and so forth until pretty much only the core language definition remains in this repository.
In parallel, this phase should establish first steps into client-side rendering support. As of right now, it is fair to say, that a framework integration for React would be the way to go.
Phase III - Revenge of the Tools
At the beginning of the third phase, the Component Engine language should be stable enough to approach tooling support.
This would also be the time to reach out and try new things, broaden host language support, figure out what can be done with the Component Engine.
Beta Was this translation helpful? Give feedback.
All reactions