[TYPO3-GSoC] Initial ideas to the Transition Solution

[Nicolas Forgerit]

Hey there,

for introducing myself: My name is Nicolas Forgerit and i'm from
Karlsruhe (Germany). I'm currently studying computer science and
physics at the local University (which by now obtained the super-fancy
name "KIT" :) ). Having worked at "punkt.de" for more than a year,
i've already become in touch with TYPO3 (v4) development.

I want to participate at your GSoC 2011 project. My favorable part
would be the transition solution for exporting T3v4 content to T3v5
Phoenix CR. Before officially submitting my proposal to you, i want to
share my initial ideas with you on this project. Please see below and
feel free to share your thoughts! :)

Best regards,
Nico

** TYPO3 GSoC 2011
URL: http://typo3.org/development/gsoc2011/ideas/exporting-typo3-v4-content-as-xml-suitable-for-import-into-a-content-repository/
*** Aims of the project
TYPO3 is right in a big rebuilding phase and will make a huge
technical step from version 4 to version 5 aka "Phoenix". Basis of the
new version will be the FLOW3 Framework which is, by the time of this
writing, just maturing into its beta phase. One of the new concepts is the
implementation of a Content Repository (CR) which transparently
persists data in form of Nodes in a hierarchical Node-Tree.
For making the transition as smooth as possible, there is a need of
functionalities to transform TYPO3v4 contents into CR-compatible data.
- discuss DDD: entities and repositories

Below there is a list of the problem space:
- T3v4's Content Elements (CE) are linked together via their PIDs. Since
  there can be a need to alter the linkings, they must be handled in a
  flexible way.
- There may be T3v4 extensions that have no direct T3v5 successor so
  the solution has to be aware of that problem
- TYPO3 is well known for its strengths concerning i18n. A solution
  for transferring T3v4 to T3v5 content needs first class support for
  internationalization (i18n) and localization (l10n)
- TYPO3v5's Node-Tree structure is not yet stable so the whole
  solution needs to be highly configurable for still being useful if
  things change (TODO: see current Phoenix implementation)
- Allow the definition of rules for exclusion of CE's and pages
- Additionally to the exceptional rules, the solution should be able
  to handle configured content types in a special way, e.g. move Nodes
  to another parent Node or reorder Page IDs.

What follows are initial ideas for the solution of the problems
introduced above (aka "solution space"):
The idea of the general structure of the solution involves two
different plugins:
1) TYPO3v4 REST-like data-provider, which uses the TYPO3v4 export-
function: sysext/impexp/app/index.php for generating the XML-based
content export.
2) FLOW3/TYPO3v5 REST-like data-importer, which receives 1)'s data and
stores it in the TYPO3CR. There will be hooks for scripts that perform
XSL transformations for adopting the T3v4 data to T3v5's
structure. Plugin #2 provides a Preferences page which let's the admin
control the following things:
- Source: URI to the TYPO3v4 installation whose contents need to be
  transformed and that installed and activated source plugin #1.
- Show and alter the linkings of the Sources pages and CE's
- Show alternatives to extensions that do not work in T3v5. Idea: Maybe we
  should set up a page for Extension Developers to provide information
  about successor plugins and extension-aware tips for transition from
  T3v4 to T3v5. These tips can be fetched and shown on the Prefereces
  page of plugin #2.
- Since XSLT is the fitting Domain-specific language for XML-based
  transformations plugin #2 provides simple hooks for a batch of
  XSLT-files. Thus the transformation can be highly configured by
  non-PHP programmers.
- Referring to exceptional rules for CE's, pages and content types,
  there is a need for a name-based and Wildcard-/Regex-enhanced
  description language for those rules.
- TODO: let's see what's currently available for storing miscellaneous
   data in the FLOW3 repository.
- BTW: Maybe it could be handy to provide (scriptable) import-
     functionalities for the CRUD repository functions that are
     REST-like controllable