When I initially started digging into Magento I experienced the same problem I had with TYPO3 years before: I needed to get to know the basic concepts, before I could productively develop clean stuff based on the system.

Soon I started to compare Magento concepts to stuff I knew from TYPO3. That made it easier to understand what's going on behind the scenes and what possibilites I have for using those concepts for my customizations and own modules.

So here is a list (a very uncomplete one) with concepts in Magento compared to TYPO3.

Basics

Let's begin with some basics. Magento and TYPO3 both are written in PHP and MySQL for storing persistent data. While Magento is based on the Zend Framework, TYPO3 is not based on anything (at least the versions below 5.X), but brings some very handy framework-like functions ready to use in your own extensions. For those of you, who love metrics and numbers: Some time ago I compared TYPO3 to some other PHP-based systems and to Magento aswell.

The big picture

A big difference between TYPO3 and Magento is, that with Magento you start with a fully working shop, while with TYPO3 you start with a blank page (or even with an error message: "No root template found" :) unless you're using a preconfigured system.

This reflects directly on the way you work with each of those systems: In Magento you spend a lot of time finding things and customize them, while in TYPO3 you construct your page from scratch. This gives you full control over the output and saves you from digging into and understanding foreign existing code, while on the other hand you'll have to take care of everything by yourself.

MVC

While Magento's architecture is clearly MVC-based, TYPO3 has something like a front-controller that delievers content and executes plugins based on the page in a pagetree.

Magento even extends the MVC-pattern by introducing layouts and blocks. There is something similar for both in TYPO3:

Layouts = TypoScript Templates

Magento's layouts can be roughy compared to TYPO3's templates (the TypoScript templates, not the HTML templates). Usually it's the layouts where you define and configure what will be displayed on the requested page. You can have multiple layout handles to organize stuff based on origin or use case. In TYPO3 this equals to having multiple TypoScript templates, possible placed on different places within the pagetree.

Layouts enable you to add stuff to the header and to compose the content and other parts on the page. Same with TYPO3. You're also free to modify previously defined settings in other handles.

Blocks = Content Elements

Magento's view layer consists of blocks. Most blocks are attached to a phtml-template, that actually renderes the output.

After triggering the model's business logic, the controller passes all needed information to blocks, that are created in the controller or defined in a layout. In TYPO3 a block corresponds to a content element (CE) or even a flexible content element (FCE) in terms of TemplaVoila. A content element can be a simple text element (would be a static cms block in Magento) or a complex frontend plugin (you're free to do whatever you need to do in a block).

Templates

In Magento phtml are used for templating. So basically it is plain php (where short syntax is used for loops and conditions). The templates are executed within the block context, so you can access the block's data and methods with $this.

In TYPO3 there are two types of templates. The old way is having text files with ###markers### and subparts. Assembling the final output the is done in PHP by parsing the files.

The new - much nicer approach - is to use fluid templates. TYPO3's new templating engine Fluid (especially in combination with TYPO3's new MVC-Framework Extbase) is much more powerful and allows you the create clean templates.

"core/text_list"-Block = COA

There are some special blocks, that are widely used within Magento. One is the _core/textlist block that is a container simply displaying its content (other blocks) one after the other.

<block type="core/text_list" name="content">
    <block type="core/text">
        <action method="setText"><param><![CDATA[Hello]]></param></action>
    </block>    
    <block type="core/text">
        <action method="setText"><param><![CDATA[World]]></param></action>
    </block>
</block>

In TYPO3 we have the COA content element ("content object array"):

lib.content = COA
lib.content {
    10 = TEXT
    10.value = HELLO

    20 = TEXT
    20.value = WORLD
}

Module = Extension

In both systems we have a way to add functionality that can be reused by creating a package. In Magento there are many terms for them (extension, module, package,..) in TYPO3 they're called extensions. Magento's module repository can be found under http://www.magentocommerce.com/magento-connect. It uses pear as underlying technology to transfer packages. Currently they're working on a new version of Magento connect.

A much more convenient way to fetch Magento packages for development is Damian's http://connect.get-the-code.de/.

TYPO3 has the TYPO3 Extension Repository (TER) and forge.typo3.org for managing, developing and distributing the extensions.

The biggest difference between Magento and TYPO3 is the way those packages are mixed with the core files: TYPO3 keeps all extensions in special folders (e.g. typo3conf/ext). All files belonging to an extension are in that folder.

Magento modules spread their files all over the core. This makes it difficult to have clean deployments, reuse modules, develop them or remove them, if you don't have a good strategy on how to setup and manage your stores. The module-manager is a good start for a clean project infrastructure.

Mage::getUrl = typolink

Magento's urls are generated using Mage:getUrl() addressing a controller action while being able to add additional parameters. In TYPO3 all links are generated via typolink (from within TypoScript of from PHP code in your extensions) while addressing a page uid and adding parameters.

Caching

TYPO3 and Magento both cache some basic stuff, that is reused often like resized images or configurations.

Both come up with a way to cache the output of your extension. In TYPO3 this is based on the chash that is generated taking the GET-parameters, the logged-in's user's groups and some other parameters (TypoScript conditions,...). In Magento you have the block caching (and in the Enterprise Version you additionally have the Fullpage-Cache, that comes close to the way TYPO3 handles the page caching).

Block caching differs from TYPO3's page caching a lot. A block is always instantiated, then it is asked for a cache-lifetime and a cache-key. Based on this information Magento decides whether to render to block or look for a cached version. Additionally you can define custom cache tags to have a fine-grained control over what cache entries should be deleted on what event. It's up to you as a module developer to decide what goes into the cache-key, that controls different versions of the block output in the cache.

Update: TYPO3 4.7 will come with some handy features that will allow fine-grained caching by introducing Magento's block level caching to TYPO3s cObjects.

Rewrites = Xclasses

In Magento most objects are created using a factory method (e.g. Mage::getModel()). In TYPO3 this is_ t3libdiv::makeInstance(). This allows you to add or overwrite functionality of the original class. In Magento this is done using so called rewrites. Additionally there is a "local" folder that has higher priority towards the "community" and "core" code folders. You can simply copy files to the corresponding path in that folder. This is not a nice solution but sometimes the only way to go, if you need to change something in a class that is not directly instantiated (but inherited from).

In TYPO3 extending classes can be done with a "xclass".

translation.csv = locallang.xml

With Magento and TYPO3 it's easy to have multilanguage output for your extensions and other parts of the website. Magento handles translations in csv files and TYPO3 uses xml files. In both systems you can always custom overwrite some translations to add more language or to change the wording of some labels.

core_config_data = localconf.php / TypoScript / Constants / ext_conf_template.txt

In Magento most settings can be changes in the backends System -> Configuration module. They're saved in a database tables called _core_configdata. As a module developer you can easyily add settings to this interface.

In TYPO3 there are several places where to put settings. TYPO3 core settings can be adapted in the install tool and the go into the localconf.php file. Extension specific settings can be defined via _ext_conftemplate.txt and also go into the localconf.php. For settings affecting the frontend rendering a developer can define constants that can be set via the constant editor. And finally settings can be done directly within the TypoScript templates.

app/etc/modules/My_Module.xml = typo3conf/ext/my_module/ext_emconf.php

TYPO3 and Magento both have a single file that contains the bare minimum information to let the system know some basic information about the extension or module.

In Magento a modules registers itself in the app/etc/modules/ folder by adding a xml file containing information on the module namespace and module name (e.g. "My_Module"), on the code pool ("local", "community" or - for core modules - "core"), a flag whether it is active of not and information on dependencies.

In TYPO3 there is a php file in the extensions's root folder called ext_emconf.php. It contains information like title, description, version number and some other stuff like author information and dependencies to other extensions, php versions or TYPO3 version.

app/code/local/My/Module/etc/config.xml = typo3conf/ext/my_module/ext_localconf.php

Besides the previously mentioned files for registering the extension, both come with some additional files to configure further features of that module.

A Magento module's most important file is the config.xml. It's here where modules, blocks, controllers, skin files, templates and many other things are registered. Besides that there are some other *.xml files in that etc folder that are used for configuring and enabling some other functionality of the module.

TYPO3 comes with the ext_localconf.php (and with ext_tables.php). It's here where most features are enabled, like registering new frontend plugins or backend modules.

Events = Hooks

Inside Magento an event/observer implementation is widely used. Observers can be easily implemented to extend or modify Magento's default behaviour. Having events dispatched in own modules is also an easy thing to do and highly recommended.

TYPO3 uses so called "hooks". Basically the concept is the sameand there a plenty of hooks all over the core. The biggest difference is that TYPO3's hooks require you to register your "observer" class or method into a $_GLOBALS variable, which isn't the most elegant implementation of this design pattern.
Also TYPO3's includes some different ways on how to process hooks. Sometimes you'll specify a class and a predifined method is called and sometimes you can specifiy the full path including your custom method. In the latest version some interfaces were introduced that must be implemented for some hook implementations.

Extbase (the widespread mvc implementation on top of TYPO3) comes with a signal/slot implementation that is much cleaner than TYPO3's hooks.

Community

This point definetly goes to TYPO3. I consider the Magento more like a "read-only" community. Developers, agencies and customers get some code from Magento, Inc and work with that. Some modules are developed and most of them are sold instead of given away for free. I don't see a spirit of contributing to the Magento core (always assuming there's a simple way to do so).

With TYPO3 this is very different. There is no commercial company behind TYPO3. Everything contributed to TYPO3 directly is available and belongs to the community. Additionally there a many events like the TYPO3 Snowboard Tour, Developer Days, Code Sprints, Typo3Camps,... that inspire people to meet each other not only on a business level, but also on a fun level. Working with and contributing to TYPO3 feels totally different than Magento.

Conclusion

So, that's my rough roundup comparing some Magento features to TYPO3 features. While both systems are hard to learn in the beginning, you'll soon learn how to do things in a quick and future-proof way very soon. Both systems have their pros and their cons, but in the end both can be fun to work with.

Comments

This website uses disqus for the commenting functionality. In order to protect your privacy comments are disabled by default.

Enable Comments