[TYPO3-GSoC] Initial ideas to the Transition Solution

["Christian Müller (Kitsunet)"]

Hi Nico,

that sounds quite good and if in the end TYPO3 has this services and a 
basic XSLT transformation in place it would be a big step forward.

We already have an XML based importer for TYPO3 v5 and v5 and v4 both 
have some REST projects, so some basics are there already, probably the 
extension handling ist a bit early right now as there basically aren't 
that much extensions for v5 out yet, but still the idea to allow 
extension developers to define a transition step could be good.

So if your application works out this might indeed be a nice project.

cheers,
Christian
TYPO3 v5 core team

On 29.03.2011 08:06, Nicolas Forgerit wrote:
> 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