Neos Code Sprint January 2013/Work Packages
This is a list of work-packages created by *Sebastian* which should be tackled hopefully somewhen this year :)
Connection between Domain Models and Nodes
Problem Description: A main strength of Neos is that we can store loosely structured content on the one side, and well-structured domain models on the other side. Depending on the problems which should be solved it makes sense to either store the data in one or the other format: E.g. for a web shop, the (well-structured) "product" might be stored in domain models (which contains prices, calculation rules, availability, ...), but the "product description" should be "loosely structured" content; where the user can add all kinds of content objects (text, images, videos, ...).
Goal: Make it possible to "mix" domain models and nodes:
- [more concrete list of TODOs, to be determined]
- document the thinking behind connecting domain models and nodes.
TYPO3 Content Repository Stability
Problem Description: The TYPO3 Content Repository stores the content tree of the TYPO3 CMS. It is vital that this storage is "robust", i.e. data loss should not happen, and effective data modification and retrieval must be possible. This means nodes should be effectively searchable, and it must be possible to define constraints on nodes (e.g. a node with a certain type must have certain properties, properties must be validatable). If node types are changed or modified, we must provide means to update the data inside the Content Repository.
- evaluate PHPCR (with doctrine) and TYPO3CR, checking the strengths and weaknesses of each
- decide whether to use PHPCR interfaces or TYPO3CR
- (depending on the decision) make it possible to search nodes
- the properties of a node must be validatable according to the node type
- design and implement node type changes, node migrations
- document TYPO3CR
Content Migration from TYPO3 CMS
Problem Description: We want to be able to migrate the basic content types from TYPO3 CMS to TYPO3 Neos in an automated way in order to ease upgrading.
- integrate the already-built prototype into Neos, test it with plain TYPO3 and TemplaVoila
- make sure the content types [X,Y,Z] are migratable to Neos
- document the content migration process
- think about migration of custom content types and plugins; at least providing a guideline for these.
Neos/Flow Package Repository
- create one package which serves as API to packagist
- create another package which is a frontend to this API, allowing to browse packages. For the neos-website.
- Integrate this into the package manager of the Neos backend
Helpful links: https://github.com/mneuhaus/Famelo.PackageCatalog
Problem Description: The current plugin integration is very basic to say the least. We need to work on that in order to make it very easy for people to write plugins and/or to turn Flow packages into a Neos plugin without having to mess with the package code. See https://forge.typo3.org/issues/40599
- improve Neos plugin API
- Polish Backend UX
- "touchless" integration of Flow packages (resolve links automatically, overridable View configuration(?), ...)
With Flow 2.0 we'll have basic REST support. But there are some annoyances and blockers that are hard to work around. There are for instance hard-coded behaviors that can't be influenced without hacks. This is relevant for Neos, because solid REST integration allows us to build Webservice support right into the core (e.g. node manipulation via API). Besides it'll make it easier for Neos developers to consume and/or provide webservices.
- collect annoyances, document ways to work-arounds or fix those
- make request handling more configurable (e.g. move argument parsing & conversion from Http\Request)
- extend routing
Improve Workspace Module
- with diff functionality, ... (bigger stuff)