MVC¶

Widgets¶

Are ready build views that understands a certain model and renders it. Currently we have two views, both can be controlled using a own php template (instead of the default):

• pagination: Use this to render pagination
• list: You can use this to render a List (the model needs to be a List (ArrayObject) of ArrayObjects)

LinkCreator¶

Is a kind of factory for the “link” viewhelper. Ask this “linkCreator” to get a new instance of a link object. You should use this linkCreator – because the linkobject it return is already initialised with the current controller argument namespace, the ajax settings etc.

There are different Methods to get predefined linkObjects. Examples:

$linkObject=$this->linkCreator->getActionLink('label','showdetail');

$linkObject=$this->linkCreator->getAjaxActionLink('ajaxshowdetail');

Link¶

Is an object representing a link. You can use the calls with chaining:

$aUrl = $this->linkCreator->getActionLink('click me','showDetail')->setParameter('uid',$id)->makeUrl();

$aURL = $this->linkCreator->getSimpleLink()->setParameter('key','value')->useOverruledParameters()->setAction('showdetail')->noCache()->makeUrl();

Label¶

Is initialised by the locallang file (default location view/locallang.xml) and should be ask in order to get languagelabels.

Example:

$this->pi_getLL('mvc.widget.previous_page');

or

$this->labels->get('mvc.widget.previous_page')

FieldRenderer¶

Is currently unfinished and has methods to render strings as something. E.g.:

$fieldRenderer->asDate(time());
$fieldRender->asRTE($mytext);
$fieldRender->asImage(...)
...

tcaFieldRenderer¶

A special fieldRenderer that intelligent decides with the help of the TCA configuration of a field how to render it for the frontend. This viewHelper is also used for the TCA presentation model and isn't finished yet.

formElementRenderer¶

Methods for getting formular elements like selectboxes, radioelement or inputelement. You can build your own selectboxes within a view or you can use the presentation models for formulars and formularelements if the forms are more complex.

Examples:

$this->formElementRenderer->renderElement($this->formModel->getElementByName('objectsformsended'));

$this->formElementRenderer->renderMVCHiddenFields();

$this->formElementRenderer->getSubmitButton();

$this->formElementRenderer->getClosingForm();

“domain” package¶

This package is currently work in progress and does not have full feature support. This is what currently works:

• load objects from database

  support for 1:n and n:1 relantion

• no storage or update currently implemented

• not all relationtypes currently implemented

This package contains abstract basis classes, that can be used to build your domain model on top of TYPO3 TCA tables:

• tx_mvc_domain_abstractObject: Abstract Baseclass for your entities.
• tx_mvc_domain_abstractRepository: Abstract Repository as entry to your domain model. It provides common repository methods like “findById”, “findAll” und “findCollectionByProperty”
• tx_mvc_domain_objectCollection: simple Object Collection, that is used if a method returns a collection of objects

Lets start with a short example. Assume that we have a “article” table, that has a “title” and a “category” where it belongs to. Category is a seperate table.

1. register your new domain class to the dependency injection manager class (Inverse of Control Manager):

tx_picocontainer_IoC_manager::registerPrototype('tx_mvcnews_domain_model_article');

2. tell the persitence framework for which table this class is responsible:

//register this class to the class2TableMapping object
tx_picocontainer_IoC_manager::getSingleton('tx_mvc_system_persitence_class2TableMapping')->addMapping('tx_mvcnews_article','tx_mvcnews_domain_model_article');

3. write your class code and add meaningful methods

/**
 * Domain Class "article"
 *
 * @author      Daniel Pötzinger
 */
class tx_mvcnews_domain_model_article extends tx_mvc_domain_abstractObject {

}

Now you can use your object:

$articleRepository = tx_picocontainer_IoC_manager::getSingleton ( 'tx_mvcnews_domain_model_articleRepository' );
$article=$articleRepository->findById(1);
$article->hasTitle();
$article->getTitle();
$article->setTitle('my title');
$categoryObject=$article->getCategory();
$categoryObject->getTitle();

You can see what the persitence concept and the domain package can do for you:

• magic methods (has/set/get)Nameofthedatabasefield
• magic resolving of relations, depending on the TCA configuration both ways are supported
  • lazy loading (aggregate or simple relation)
  • preloading (composition)

“ddd” package¶

There are basic model classes. they are more a data wrapper – wrapping a single row of a table into an object. For complex applications you have to create your own model classes with behaviour and business logic. For the common data wrapping obejcts – that needs a row of data from a database table you can use the classes inside of the mvc framework:

• tx_mvc_abstractDbObject – a simple object that is constructed with a row of any table. You can then access all properties with methods like $obj->getTitle() and $obj->setTitle('new title')
• tx_mvc_abstractRepository – a simple repository – use this to get (find methods) add(), save() and update() objects
• tx_mvc_abstractTCAObject - similar to the abstractDbObject – but it has some more nice functions based on the TCA configuration of the table.
• tx_mvc_abstractTCAObjectRepository - A repository to find, add(), save() or update() TCAobjects. It has build in functionality to use workspace and language overlays before returning an object.

Some notes on the concept: Each of that abstract domain classes uses functions from a system layer to access the persistence data in the database.

view helper:¶

Are objects that contains common helper methods for views. For example:

• helping generation links
• helping rendering strings
• helping getting language labels
• helping generating formulars
• some custom helpers that have reoccurring snippets (like buttons, special icons)

In this extension viewHelpers are “injected” to the view, there will be a Hook that allows you to inject custom viewHelpers.

composite view:¶

Doublicate of code is always something smelly – so for example you may always require the same pagebrowser – then you want to write the rendering for this in just one place. “view helpers” are one way to deal with that. The composite view pattern is another.

This is a view that composes several other views. For example imagine a typical listview: You have a search form, then a pagebrowser then a table with the list of items. So you can imagine this view as a composition of several SubViews (a pageBrowserView a SearchView and a ListView).

If you want to have a composite view – just use one of the view classes and add some methods to register your “subviews”. See the example extension for an example.

transform view¶

Another type of view is transformview – as the name says: It simply takes input and transforms it to have a different output. (For example a htmlToPDFTransformView).

In this extension there is a special interface for transformViews.

Supported configuration¶

The framework is aware of some configurations per default:

To disable the injection of the build in viewHelpers you can add this to your configuration:

configuration {
 viewHelper.disable {
  linkCreator=1
  label=1
  fieldRenderer=!
 }
}

To configure the correct building of Ajax Links:

configuration {
 ajaxPageType=xxxxx
}

Suggested Namespace for configuring the TCA presentation model:

configuration {
  presentationModel {
                <tablename> {
                        <columnname> {
                                (your configuration)
                        }
                }
  }
}

Finding the relevant controller (request building) and dispatching:¶

When plugins are added to a page this is how it is dispatched:

The informations required to find the responsible controller comes from TYPO3, because the CMS decides which page should be shown and which plugins and/or typoscript objects are added to that page. Technically the simplePluginFrontController (or switchedPluginFrontController) get control from TYPO3 in order to return the output for the concrete plugin instance. The request-object is technically build from the typoscript configuration (that this concrete instance has) – this request is then simply passed to the dispatcher. And finally the content is returned by a controller.

Of course there can be multiple instances of plugins on one page. So imagine every plugin instance as a separate MVC part! You should have this is mind – thats a difference to common MVC frameworks where you don't have the TYPO3 CMS with all its concepts like pagetree, typoscript, pagerendering etc. Because you can have multiple plugins on a page and other plugins on other pages you have to tale care of:

• TYPO3 decides the order of executing your plugins. Have that in mind when you change state or session of you application on a controller Action. (read the text abaout global front controllers when you run into issues with that)
• If you link to a certain controller/action you might need to know the pageId for it. (Use configuration to configure the pageId for certain links)

Global Controllers¶

We introduced the concept of a “global controller”. Such controllers are not allowed to produce any output. They are called before pagerendering starts. Therefore there are useful to listen for actions that change the state or session of your application. If this state is used by multiple plugins – its a good idea to put the change logic inside of a global controller. This ensures that the updated state is always available for the normal plugins.

In the framework there is the globalFrontController that offers a concept of calling controllers independent from the current page. Controllers needs to be registered as a global controller – in order to support dispatching.

How controllers are executed in TYPO3:¶

There are some supported ways of how your controller can be executed with the help of this framework:

A MVC Plugin is configured in TYPO3 and is executed by TYPO3 during the page rendering – there are this possible ways:

as plugin contentelement on a page:

this can be a simple plugin configuration (representing exact one controller)

or a “switched” plugin, than the flexform needs to be read to detect the controller that should be used for the concrete plugin instance .

as typoscript (=simple plugin configuration)

as AJAX pagetype (see Ajax section for details)

global available controllers can be called independent from plugins on a page, they are executed before any plugin requests. Use this in order to execute preparing Actions, or actions that changes state for more that one other controller (plugins on the page) (like deleting something in a session or modifying something that is relevant for several plugins on a page – normally this is only required in complexer applications). Controllers that act as global controllers are not allowed to return any output (of course).

Simple Plugin¶

Is configured with this php code in ext_localconf.php:

$pluginListTypeKey=$_EXTKEY.'_plugin';
tx_mvc_extMgm::addSimplePluginController($_EXTKEY,$pluginListTypeKey,'default');

And technically it adds this typoscript:

As you see the configuration for the controller is taken from the common controller configuration namespace “plugin.tx_objects_controller_uncachedtest.configuration” Use this path to add common configuration within the static template.

For registering it really as a plugin (that it is available in the contentelement) you still have to place this in ext_tables.php:

$pluginListTypeKey=$_EXTKEY.'_plugin2';
t3lib_extMgm::addPlugin(array('LLL:EXT:objects/locallang_db.xml:tt_content.list_type_pi2',$pluginListTypeKey),'list_type');

And if you like of course the static typoscript configuration template:

t3lib_extMgm::addStaticFile($_EXTKEY,"configuration/static/","Objects Outputs");

Switched Plugin¶

A switched pugin is a plugin where multiple controllers can belong to. Then you need to have a flexform configuration with a selectbox that represents the controllerswitch:

Is added with:

$pluginListTypeKey=$_EXTKEY.'_plugin';
tx_mvc_extMgm::addSwitchedPluginController($_EXTKEY,$pluginListTypeKey,array('default','uncachedtest'),'commonsettings.field_controller',0);

|img-5|

Also you need to place this lines in ext_tables.php:

$pluginListTypeKey=$_EXTKEY.'_plugin';
t3lib_div::loadTCA('tt_content');
$TCA['tt_content']['types']['list']['subtypes_excludelist'][$pluginListTypeKey]= 'layout,select_key,pages,recursive';
$TCA['tt_content']['types']['list']['subtypes_addlist'][$pluginListTypeKey]='pi_flexform';
t3lib_extMgm::addPlugin(array('LLL:EXT:objects/locallang_db.xml:tt_content.list_type_pi1',$pluginListTypeKey),'list_type');
t3lib_extMgm::addStaticFile($_EXTKEY,"configuration/static/","Objects Outputs");
t3lib_extMgm::addPiFlexFormValue($pluginListTypeKey, 'FILE:EXT:'.$_EXTKEY.'/configuration/flexform.xml');

Adding controllers as typoscript object¶

You simply configure your “simplePluginFrontController” in a typoscript object like this:

lib.myobject=USER
lib.myobject {
 userFunc= tx_simplePluginFrontController->main
 controller {
     configuration < plugin.tx_objects_controller_default.configuration
     configuration {
             myextraconfigurationforthisobject=something
     }
     controllerName= default
     extension=objects
 }
}

AJAX Page Types¶

The default concept for adding AJAX functionality is to configure a special pagetype for each controller. This is done in that way:

$pluginListTypeKey=$_EXTKEY.'_plugin';
tx_mvc_extMgm::addAjaxResponsePageType($_EXTKEY,$pluginListTypeKey,'default',9112008,'objects');

This results in that typoscript:

The framework will than takes care that the AJAX call has exactly the same configuration like your plugin (also flexform configuration is loaded)

Using a seperate pagetype has the advantages of: TYPO3 cache support – even static cache if you want, full TYPO3 environment, good performance since no TYPO3 templates needs to be rendered for that pagetype.

AJAX with eID¶

As mentioned the default concept of AJAX is to configure a AJAX pagetype with the correct typoscript etc. This way you have initialised TYPO3 environment, access to typoscript, typolink, cObj etc.

However there might be reasons where you don't need typoscript and a full initialised TSFE etc. - so you can create a eID script for answering your ajax calls. This is how it works:

1 – register eId script in your extension (ext_localconf.php):

$TYPO3_CONF_VARS['FE']['eID_include']['eft_postpaidconfigurator'] = 'EXT:eft/typo3/eid_postpaidConfigurator.php';
2 place this code in this script:
<?php
require_once t3lib_extMgm::extPath('mvc') . 'mvc/class.tx_mvc_eIdFrontControllerService.php';
$feUserObj = tslib_eidtools::initFeUser(); // Initialize FE user object
$uid=t3lib_div::_GP('mvcinstance');
$response=tx_mvc_frontControllerService::start('eft','postpaidConfigurator',array(),$uid);
echo $response->getContent();
?>

That means the eId script is responsible for getting the configuration and it determines the extension and controller that should be used to answer the request. The idea is to create and register seperate eId scripts for each controller where you want ajax eId support

Creating Links:

You can use the linkCreator:

->getEIDActionLink('eft_postpaidconfigurator', 'someAjaxAction')

Hooks¶

The MVC extension has several Hooks that can be used to modify behaviour – every hook has an interface in mvc/hooks/ that contains more descriptions.

For example there is a hook that allows to add own view helpers, by injecting them into the view during the initializeView() method.