[Typo3-dev] Normalisation / OOP - a Case Study (ObTS)

[Martin Poelstra]

Hi All,

Normalising and OOP-ing TYPO3 seems like a good idea, but it's certainly
true that it would be a bad idea if current code can't be used anymore (like
tons of extensions).
However, the same was said about the database abstraction layer! That layer
was created, and it works perfectly fine together with the 'old way' of
doing things. We can imagine that some day in the future, some extensions
won't work anymore if they aren't converted to the DBAL, but for now, both
technologies work.

Couldn't the same principle be followed for OOP-ing the rest of TYPO3?
Suppose we make a set of classes to retrieve/change things in the DB, like
this (which is a completely stupid piece of code, just to show what kind of
functions/classes will exist):

global $TYPO3_root;
$page->$TYPO3_root->getPageFromID(123);
$title = $page->getTitle();
echo('Users in the group of page '.$title.'<br />');
$subpages = $page->getSubpages();
foreach($subpages as $subpage) {
  $group = $subpage->getGroup();
  if ($group) {
    $user = $group->getUsers();
    foreach($users as $user) {
      $username = $user->getUsername();
      echo($username.'<br />');
    }
  }
}

With an approach like this, we can have 'several' implementations of e.g.
the $user-, $page- and $group-classes. One (possibly the first)
implementation will be the version that works with the *current*
TYPO3-tables etc.

Now, extension-developers can be motivated to use this new scheme, exactly
like many developers are switching to the DBAL-classes now. Then, another
implementation of the classes can use an entirely different approach,
possibly adding new functionality (like Access Control Lists for access to
the pages, content elements, etc. instead of the current 'Unix-way').
Ofcourse, some extensions will gradually fail to work, but this is no
different from e.g. DBAL, or the normal upgrades of TYPO3: some extensions
originally written for 3.5 don't work in 3.7 anymore. But now the changes
are very smooth...

So, I'd like to vote for the DBAL approach, but 'bigger'.

Grtz,
Martin