// Classes/Controller/AbstractModController.php

require_once(PATH_tslib . 'class.tslib_fe.php');
require_once(PATH_t3lib . 'class.t3lib_userauth.php');
require_once(PATH_tslib . 'class.tslib_feuserauth.php');
require_once(PATH_t3lib . 'class.t3lib_cs.php');
require_once(PATH_tslib . 'class.tslib_content.php');
require_once(PATH_t3lib . 'class.t3lib_tstemplate.php');
require_once(PATH_t3lib . 'class.t3lib_page.php');

class Tx_Test_Controller_AbstractModController extends Tx_Extbase_MVC_Controller_ActionController {

	public function initializeAction() {
		$this->buildTSFE();
	}

	private function buildTSFE() {
		if (!is_object($GLOBALS['TT'])) {
			$GLOBALS['TT'] = new t3lib_timeTrack;
			$GLOBALS['TT']->start();
		}

		$TSFEclassName = t3lib_div::makeInstance('tslib_fe');

		$GLOBALS['TSFE'] = new $TSFEclassName($GLOBALS['TYPO3_CONF_VARS'], $this->pid, '0', 1, '', '', '', '');
		$GLOBALS['TSFE']->connectToMySQL();
		$GLOBALS['TSFE']->initFEuser();
		$GLOBALS['TSFE']->fetch_the_id();
		$GLOBALS['TSFE']->getPageAndRootline();
		$GLOBALS['TSFE']->initTemplate();
		$GLOBALS['TSFE']->tmpl->getFileName_backPath = PATH_site;
		$GLOBALS['TSFE']->forceTemplateParsing = 1;
		$GLOBALS['TSFE']->getConfigArray();
	}

	private function uriFor($targetPageUid, $actionName = NULL, $controllerArguments = array(), $controllerName = NULL, $extensionName = NULL, $pluginName = NULL, $format = '', $argumentPrefix = NULL) {
		if ($actionName !== NULL) {
			$controllerArguments['action'] = $actionName;
		}
		if ($controllerName !== NULL) {
			$controllerArguments['controller'] = $controllerName;
		} else {
			$controllerArguments['controller'] = $this->request->getControllerName();
		}
		if ($extensionName === NULL) {
			$extensionName = $this->request->getControllerExtensionName();
		}
		if ($pluginName === NULL && TYPO3_MODE === 'FE') {
			$pluginName = Tx_Extbase_Utility_Extension::getPluginNameByAction($extensionName, $controllerArguments['controller'], $controllerArguments['action']);
		}
		if ($pluginName === NULL) {
			$pluginName = $this->request->getPluginName();
		}
		if ($targetPageUid === NULL && TYPO3_MODE === 'FE') {
			$targetPageUid = Tx_Extbase_Utility_Extension::getTargetPidByPlugin($extensionName, $pluginName);
		}
		if ($format !== '') {
			$controllerArguments['format'] = $format;
		}
		if ($argumentPrefix !== NULL) {
			$prefixedControllerArguments = array($argumentPrefix => $controllerArguments);
		} else {
			$pluginNamespace = Tx_Extbase_Utility_Extension::getPluginNamespace($extensionName, $pluginName);
			$prefixedControllerArguments = array($pluginNamespace => $controllerArguments);
		}

		return $prefixedControllerArguments;
	}

	protected function buildFrontendUri($targetPageUid, $actionName = NULL, $controllerArguments = array(), $controllerName = NULL, $extensionName = NULL, $pluginName = NULL, $noCache = false, $useCacheHash = true, $createAbsoluteUri = true, $format = '', $argumentPrefix = NULL) {

		$this->uriBuilder->reset();
		$this->uriBuilder->setNoCache($noCache)
				->setUseCacheHash($useCacheHash)
				->setCreateAbsoluteUri($createAbsoluteUri)
				->setArguments(
			$this->uriFor($targetPageUid, $actionName, $controllerArguments, $controllerName, $extensionName, $pluginName, $format, $argumentPrefix)
		);

		return $this->uriBuilder->buildFrontendUri();
	}
}

So what exactly is the problem why extbase cannot build frontend uris in the backend? Short answer: Because extbase uses the TYPO3 core to build uris and the core has to have a fully functional TSFE to build frontend uris that does not exist in the backend. So the litte fix here is to build our own TSFE with the least configuration necessary. Having the TSFE globally available we are able to build frontend uris but still extbase behaves not the way we want. The usual uriFor function does not behave like the one in our controller. If you want to know more about it, compare it on your own. Important is, that we get the frontend uri params back so we can put them into the standard uriBuilder to build the frontend uri.

So, let’s see next how to actually use this in our backend module. Again some code:

// Classes/Controller/ModController.php

class Tx_Test_Controller_ModController extends Tx_Test_Controller_AbstractModController {

	public function indexAction() {
		return $this->buildFrontendUri(5, 'action', array(), 'controller', 'tx_ext', 'pi1', true, false, true);
	}
}

So, this controller inherits all the methods from the first controller, means we can now access the buildFrontendUri action of the parent controller and build all needed uris. Just try it out, play around and have fun.

Any questions? Leave a reply.

It’s very easy. Extbase uses a nice feature, called reflection, you can read PHP comments (PHP docs) with. Exactly, these annotation you make in your source code. And for sure this process takes quite a lot of cpu power, so the developers of extbase implemented a cache for all these annotations for not doing the reflection every time. And it’s great in production environments, but if you are developing your domain models it’s just annoying because you have to delete the cache every time.

So here’s how you can disable the caching for extbase.

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['extbase_reflection']['backend'] = 't3lib_cache_backend_NullBackend';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['extbase_object']['backend'] = 't3lib_cache_backend_NullBackend';

Just place these lines in your localconf.php.

But be sure you are using TYPO3 4.6, means using the caching framework with the extbase caching tables as follows:
cf_extbase_object
cf_extbase_object_tags
cf_extbase_reflection
cf_extbase_reflection_tags

Alright.
Hope that helps you saving time and pain during your coding fun.

And as always, leave a reply if you want.

Instead I want to introduce another way having the ability to use all the features TYPO3 and Extbase come with. So, let’s get started with a very small new extension. Btw: I recommend you to check out my example extension on github for a better understanding of what I am talking about now.

So, what has to be done. At first you need a working Extbase extension with just one controller, two actions and one template for one of these actions. To keep it simple there is no model, no repository, nothing but the controller.

class Tx_AsAjaxexample_Controller_ExampleController extends Tx_Extbase_MVC_Controller_ActionController {

    /**
     * @return void
     */
	public function indexAction() {
    }

    /**
     * @return void
     */
	public function ajaxAction() {
        $json = array(
            'jQuery',
            'ExtJS',
            'Prototype',
            'MooTools'
        );

       return json_encode($json);
	}
}

The index action does nothing else but render the template. The ajaxAction is a bit special as I do not use the render function but return a json encoded static array (line 20). This is done because the rendering of Fluid uses htmlspecialchars and destroys the JSON string. Now there is another problem. Calling the ajaxAction in the frontend you get valid JSON but also the HTML-structure of your standard template wrapped around it. To avoid that, typoscript comes into play. Let’s have a look at it:

ajaxPage = PAGE
ajaxPage {
    typeNum = 99
    config {
        disableAllHeaderCode = 1
        additionalHeaders = Content-type:application/json
        xhtml_cleaning = 0
        admPanel = 0
    }

    10 < tt_content.list.20.asajaxexample_pi1
}

All the magic here is to create a new PAGE object with a typeNum different from “0″ (line 2) and assign the content of the extension to the blank page (line 11). Adding type=99 to the request url let’s this PAGE come into play and outputs nothing else but what we need, the JSON string. Please be sure not to print the parsetime ( <!-- Parsetime: 254ms --> ) by adding the following line to your localconf.php:

$TYPO3_CONF_VARS["FE"]["debug"] = '0';

Now we’re ready to put the plugin on a site and view it in the frontend. In case you are not using my example extension here’s the template for you:

<button id="ajax">fetch list</button>
<button id="clear">delete list(s)</button>
<div id="list">List(s):</div>

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js"></script>
<script type="text/javascript">
ajaxUrl = "{f:uri.action(action:'ajax', pageType:'99')}";

(function($) {
    $(document).ready(function(){

        $('#clear').click(function(){
            $('#list').text('List(s):');
            return false;
        });

        $('#ajax').click(function(){
            $.getJSON(ajaxUrl, function(data) {
                var items = [];

                $.each(data, function(key, val) {
                    items.push('<li id="'   key   '">'   val   '</li>');
                });

                $('<ul/>', {
                html: items.join('')
                }).appendTo('#list');
            });

            return false;
        });
    });
})(jQuery);
</script>

Update: Added return false; to the click-functions for disabling their normal submit-behaviour.

I guess the code is self-explaining. There’s one button to do the request, one to clear the DOM and a placeholder div for the result. The rest is easy JS with jQuery. Having my extension installed you can now test it. As you probably can see it’s not super-fast but also not too bad. I did some tests with firebug and the request mostly took about 300ms.

Alright, that’s it again. Hopefully that is a little help in your daily business.

Useful Links:

• Tsref: PAGE
• Ext: as_ajaxexample on github

Something you didn’t understand? Leave a reply.

Imagine you are about to build a form that creates a new object, let’s say a frontend user. Probably the user needs an email address as a unique identifier to log in with later on. So the model has a property called email.

class Tx_ExtensionName_Domain_Model_ModelName extends Tx_Extbase_DomainObject_AbstractEntity
{
    /**
     * @var string
     * @validate Tx_Extbase_Validation_Validator_EmailAddressValidator
     */
    protected $email= '';
}

If you know my post about setting own error messages this example might look very familiar. As you can see, the property is a simple string and we already have the validate annotation to verify the given address. So far there’s nothing new. The validation ensures that the address itself is valid but how do we check if it’s unique inside our environment? That’s where validation classes come into play.

Whereas annotations validate a single property against mostly just one rule, validators are more powerful as they are able to run a whole set of more complex validations within a different context. Keeping it simple you can say that property annotations take care that an object itself is consistent during its lifetime. Validators instead are set in the context of controller actions that handle the whole object, e.g when passing a new object to a create action. Some code for a better understanding:

class Tx_ExtensionName_Controller_ModelNameController extends Tx_Extbase_MVC_Controller_ActionController {
{
    /**
     * @param Tx_ExtensionName_Domain_Model_ModelName $newObject
     * @validate $newObject Tx_ExtensionName_Domain_Validator_ValidatorName
     */
    public function createAction(Tx_ExtensionName_Domain_Model_ModelName $newObject)
    {
        $this->modelNameRepository->add($newObject);
    }
}

It’s line five that defines that the new object has to be validated against the vaildation class. Let’s switch to the validator itself:

class Tx_ExtensionName_Domain_Validator_MyValidator extends Tx_Extbase_Validation_Validator_AbstractValidator
{
    /**
     * @var Tx_ExtensionName_Domain_Repository_ModelNameRepository
     */
    protected $modelNameRepository;

    /**
     * @param Tx_ExtensionName_Domain_Repository_ModelNameRepository $modelNameRepository
     * @return void
     */
    public function injectModelNameRepository(Tx_ExtensionName_Domain_Repository_ModelNameRepository $modelNameRepository)
    {
        $this->modelNameRepository = $modelNameRepository;
    }

    /**
     * @param Tx_ExtensionName_Domain_Model_ModelName $value
     * @return bool
     */
    public function isValid($value)
    {
        $this->errors = array();

        if ($this->modelNameRepository->findByEmail($value->getEmail())->count() > 0) {
            $this->errors['email'] = new Tx_Extbase_Validation_PropertyError('email', time());
            $this->errors['email']->addErrors(array(new Tx_Extbase_Validation_Error('Email not unique', 84647862842)));

            return false;
        }

        return true;
    }
}

Now it becomes interesting. Actually the “isValid”-method acts as a constructor, so you can write validators with just that method if you do not need any other logic. In this case we need access to a repository so there also is an inject method. If you do not know what’s going on, search for dependency injection (DI) in general and how it’s implemented in Extbase (since 1.3) in particular.

Having access to the repository, we can check if there’s a frontend user with the given email address yet. If so set errors and return false, else return true. But let’s see what’s happening in line 26 and 27. Again, as I mentioned in my post about setting error messages, there is an error cascade beginning with a Tx_Extbase_MVC_Controller_ArgumentError that is related to the handled object, e.g. the new frontend user. That object contains a Tx_Extbase_Validation_PropertyError for every property that is not valid. And for each validation that fails there is a Tx_Extbase_Validation_Error that holds an error message to display in the form. So, if there’s a matching frontend user we add a Tx_Extbase_Validation_PropertyError to the error array first. Now we know that the email property isn’t valid but what exactly went wrong tells us the Tx_Extbase_Validation_Error we assign in line 27. It took me quite a while to discover how add errors but once you know it, it absolutely makes sense and is very convenient, too.

Perhaps I should drop some lines about the error codes at last. Well, as you see, I just used time() for the Tx_Extbase_Validation_PropertyError as I don’t care about the message. But the Tx_Extbase_Validation_Error should have a certain error code you can access its related message with. I did not find a convention about how to choose an appropriate number but I recommend to take something very high or low and just increase the number by one for every validation error you create. I guess, I do not have to mention that you should not overwrite existing error codes, do I?

Useful links:

• http://en.wikipedia.org/wiki/Dependency_injection
• http://forge.typo3.org/projects/typo3v4-mvc/wiki/Dependency_Injection_%28DI%29
• Tx_Extbase_Validation_Validator_AbstractValidator

And as usual: Found a mistake? Have a question?
Just leave a reply!

To be honest, I don’t really like the solution I am presenting you but it’s very convenient. As we are working with partials you should know what it is. If not, the next paragraph is for you, else head on to the next section.

A partial is nothing else but a part of code, most common a reusable one that represents some logic you need again and again. For instance an error list you put an error object in and once you defined how to process it you don’t care anymore in future projects. Just copy the partial, put in another object and the rest is pure magic. If you are used to object oriented programing, I guess you are, you can see the similarity.

Creating the Partial

It’s recommended that you put partials in a folder named “Partials” next to the templates folder. The full path is EXT:Resources/Private/Partials/.

Once you put in a partial, let’s say PartialName.html, you are able to render it inside your views with the use of the following Fluid render tag.

<f:render partial="PartialName" arguments="{arguments}" />

We will have a look at the arguments later, up to now its only necessary to know you can pass arguments in. So, here is the field error partial:

<!-- PartialName.html -->
<f:form.errors for="{objectName}">
    <f:if condition="{0:error.propertyName} == {0:'{propertyName}'}">
        <f:for each="{error.errors}" as="errorItem">
		    <f:translate key="error.{error.propertyName}.{errorItem.code}" htmlEscape="false">Not translated: [{errorItem.message} ({errorItem.code})]</f:translate>
        </f:for>
    </f:if>
</f:form.errors>

Similar to rendering a whole list we also iterate through all errors in this case except that we check if a certain error occurred. If so, we echo it via the translate tag I yet wrote about in my last post. I know, it’s a dirty way accessing a single error and I am curious about any other possible solution but I guess this one doesn’t take too much memory or CPU time.

Alright, we have to combine the partial with a fitting render tag now because we now need the arguments left out in my example above.

<f:render partial="FieldError" arguments="{objectName: 'newPerson', propertyName: 'email'}" />

The arguments object contains two properties called objectName and propertyName. Both are strings you just have to replace inside your project. In this example we want to create a new object named newPerson with an email property. These arguments are now available inside the partial and we are able to check whether the it’s an invalid email address. Most probably you place the render tag next to your input field but no matter where you put it, please do not build a list with it.

Any questions? Leave a reply.

So the first thing I wanted to know, is how to develop a file uploader based on web standards with having the ability to show a progress bar. Now that I write this post, this is a very hot topic because I neither found much information about it nor did I see any website having this feature except Youtube.

As we are talking about the client side of the uploader first it’s all about javascript now. So, a basic understanding of this language is necessary.

Still with me? Alright, what do we need to build this uploader? Simple said it’s two features named File API and XHR2. Never heard of? No problem. Let’s first have a look at the File API.

The File API

The API provides access to the files stored on your hard disk and numerous file operations on these. Having a closer look you recognize that the API includes a bunch of new objects with powerful functionality bringing the web and your desktop very close together. But to build an uploader we just focus on two objects:

1. FileList
2. File

While the File object represent a real file on your hard disk and lets you access its information through some properties and methods the FileList object acts as an array or a storage of File objects you can easily iterate through.

To select a file we use the following input tag, introduced 1997, when uploading 100k must have been a pain in the ass for everybody.

<input type="file" id="file" />

Clicking on the button a window appears that lets you select a file. Sure, you are used to expect nothing as you chose one but you can change this by binding an event handler to the input field.

var input = getElementById('file'); 
input.addEventHandler('change', callbackFunction);

function callbackFunction(event) {
    var FileList = event.target.files;
    var File = FileList[0];
}

In line 5 we find all the magic. We can access a FileList object through the Event object that is fired when changing the input element. We always get a FileList, even when only selecting one single file but in line 6 you can see how to access it. I recommend you to build this small example, install Firebug and debug the File var.

That’s it for the File API part. Next we have a look at XHR2.

XMLHttpRequest2

I’m sure you heard of XMLHttpRequest, the magic that brought Web 2.0 to life. The XHR object gave us the possibility of asynchronious HttpRequests so we can load/send data from/to a server without doing a page reload. So we were able to send/upload data ever since this object was available first but with the support of the second version we got a new property named upload. Here some code for a better understanding:

xhr = new XMLHttpRequest();
xhr.upload.addEventListener("progress", onUploadProgress);

// void open(DOMString method, DOMString url, boolean async);
xhr.open('post', 'url', true);

xhr.upload is of type XMLHttpRequestUpload, a new object that is shipped with a special Event called progress that is fired as long as the upload of data takes time giving information about the current upload status.

xhr = new XMLHttpRequest();
xhr.upload.addEventListener("progress", onUploadProgress);

// void open(DOMString method, DOMString url, boolean async);
xhr.open('post', 'url', true);
xhr.setRequestHeader("Content-Type", "application/octet-stream");
xhr.setRequestHeader("X-File-Name", File.name || File.fileName);
xhr.setRequestHeader("X-File-Size", File.fileSize);
xhr.setRequestHeader("X-File-Type", File.type);

if ('getAsBinary' in File)
	xhr.sendAsBinary(File.getAsBinary());
else
	xhr.send(File);

function onUploadProgress(event) {
    if(event.lengthComuptable) {
        log(Math.round((event.loaded * 100) / event.total) + '%');
    }
}

Here we got a bunch of new lines. First of all we have to imagine that we have a variable called File in this context that holds a real File object we chose using the input field. As you can see we set some http headers to let the server know how to handle the uploaded file. In line 7 we access the filename either through the name or fileName property of our File object wheras name is the standard and fileName is how Firefox 3.5 named this property.

Next we start the upload with xhr.send(File). Due to Firefox 3.5 there is an exception in Line 12 again.

After starting the upload the callback function onUploadProgress is fired as long as the upload isn’t finished. As you can see we can access the bytes already loaded and the total bytes to compute the percentage of our upload progress. That’s very equal to working with ActionScript.

Last and least there are two possibilities to to handle the upload success as the xhr object itselt and the xhr.upload property may fire an Event on success. But while the xhr object may retriece data from the server, e.g. some JSON, the upload property just informs you about whether the upload has failed or not.

The Server Side (PHP)

Depending on the server technology you are using the processing of uploaded data is different. In this case we have a look at how to handle the upload with PHP as this is widely used.

The traditional way of uploading and processing  files is through an HTML form that sends the data via POST to the server where the uploaded file is available in the global $_FILES var. Using xhr there is no $_FILES var but you can directly access the PHP input stream.

$fileName = $_SERVER['HTTP_X_FILE_NAME'];

$input = fopen('php://input', 'r');
$output = '/your/path/' . $fileName;

while ($data = fread($input, 1024))
	fwrite($output, $data);

fclose($input);
fclose($output);

There is just one more thing I want to show you. Imagine the user wants to upload a huge file, let’s say 50M. You might want to give him the chance to cancel the upload to not wait until the upload is finished. But with this script a file will be written even if  you uploaded just 1K. This can cause a lot of trash on your server and I hate waisted files. Hope, you too.

The solution is quite easy as we just have to compare the filesize of the uploaded file with the filesize we set in the http header.

$fileName = $_SERVER['HTTP_X_FILE_NAME'];

$input = fopen('php://input', 'r');
$output = '/your/path/' . $fileName;

while ($data = fread($input, 1024))
	fwrite($output, $data);

fclose($input);
fclose($output);

if(filesize($fileName) != $_SERVER['HTTP_X_FILE_SIZE'])
	unlink($fileName);

If the sizes don’t match, the written file will be deleted and no trash is left behind.

Useful Links:

• http://www.w3.org/TR/FileAPI/
• http://www.html5rocks.com/en/tutorials/file/dndfiles/
• http://www.w3.org/TR/XMLHttpRequest2/
• http://www.html5rocks.com/en/tutorials/file/xhr2/

In this first part of my series I write about setting own error messages instead of using the system ones. Ready? Here we go!

How to set own error messages?

At first we need to know when errors occur. That’s quite easy because there are just two cases:

1. Using annotations to validate model properties against one single rule
2. Using your own validator class for more complex validation.

So, when validating your model properties with annotations you can either use all the validators Extbase has on board or write your own ones. In case you want to verify an email-address it makes sense using the built-in validator because it provides a nice regular expression you probably not want to write again. Let’s see some code:

class Tx_ExtensionName_Domain_Model_ModelName extends Tx_Extbase_DomainObject_AbstractEntity
{
    /**
     * @var string
     * @validate Tx_Extbase_Validation_Validator_EmailAddressValidator
     */
    protected $email= '';
}

This part is your own model with an email property you want to validate.

class Tx_Extbase_Validation_Validator_EmailAddressValidator extends Tx_Extbase_Validation_Validator_AbstractValidator {

	public function isValid($value) {
		$this->errors = array();
		if(is_string($value) && preg_match('
				/
					^[a-z0-9!#$%&\'*+\/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&\'*+\/=?^_`{|}~-]+)*
					@
					(?:
						(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[a-z]{2}|aero|asia|biz|cat|com|edu|coop|gov|info|int|invalid|jobs|localdomain|mil|mobi|museum|name|net|org|pro|tel|travel)|
						localhost|
						(?:(?:\d{1,2}|1\d{1,2}|2[0-5][0-5])\.){3}(?:(?:\d{1,2}|1\d{1,2}|2[0-5][0-5]))
					)
					\b
				/ix', $value)) return TRUE;
		$this->addError('The given subject was not a valid email address.', 1221559976);
		return FALSE;
	}
}

And this one is the given validator class.

Now, when using this validator, it causes the standard error message “The given subject was not a valid email address.“. Either you simply want to change the message to sth. more fitting like “Sorry dude, please enter a valid email address” or translate it into another language there’s the same easy solution for both cases: The Fluid translation tag.

Btw. you should have a look at the blog_example. Most of my knowledge I do have from this extension.

<f:translate key="LLL:EXT:extension/Resources/Private/Language/locallang.xml:key" />

There’s also the possibility to use this tag “inline” but it’s not that important in this blog post. Nevertheless you should have a look at it as most Fluid tags can be used this way.

<img alt="{f:translate(key:'LLL:EXT:p/a/t/h/locallang.xml:key')}" />

Before showing you the template with it’s error part and how to actually combine it with the translation tags, I need your attention because the way you access errors is a bit special and worth being explained in a few sentences. Here we go:

In your template you can access all occurring errors through one object of type Tx_Extbase_MVC_Controller_ArgumentError. Let’s say you have ten properties to validate and all of them produce an error, than your error object contains an array of ten objects of type Tx_Extbase_Validation_PropertyError inside. Each of these objects also has an array to store multiple objects of type Tx_Extbase_Validation_Error.

Does not make sense? It does! While the first array contains all the Tx_Extbase_Validation_PropertyError objects for each property that threw an error, the second array inside the Tx_Extbase_Validation_PropertyError object contains all Tx_Extbase_Validation_Error objects related to the property itself. Still not clear?

Imagine you have more than one validation rule for a property. Perhaps you want an email address to be valid and unique inside your system environment, then you have to validate against two validation rules that can throw an error message each. For a better understanding here is a visualisation of it:

Tx_Extbase_MVC_Controller_ArgumentError Object
(
    [message:protected] => Validation errors for argument "newObject"
    [code:protected] => 1245107351
    [propertyName:protected] => newObject
    [errors:protected] => Array
        (
            [email] => Tx_Extbase_Validation_PropertyError Object
                (
                    [message:protected] => Validation errors for property "email"
                    [code:protected] => 1242859509
                    [propertyName:protected] => email
                    [errors:protected] => Array
                        (
                            [0] => Tx_Extbase_Validation_Error Object
                                (
                                    [message:protected] => The given subject was not a valid email address.
                                    [code:protected] => 1221559976
                                )
                            [1] => Tx_Extbase_Validation_Error Object
                                (
                                    [message:protected] => The email address is not unique.
                                    [code:protected] => 1221559989
                                )
                        )
                )
	)
)

In the following code I just iterate through the error array of a single Tx_Extbase_Validation_PropertyError object while property.errors is the error array.

<ul>
<f:for each="{property.errors}" as="propertyError">
    <li>
        {propertyError.message}
    </li>
</f:for>
</ul>

Now there's not much more to do or understand. Instead of showing the original error message we use a translation tag.

<ul>
<f:for each="{property.errors}" as="propertyError">
    <li>
        <f:translate key="error.{property.propertyName}" htmlEscape="false">Not translated: [{propertyError.message}]</f:translate>
    </li>
</f:for>
</ul>

So we can easily access our desired/translated error message. The corresponding locallang.xml should look like this:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
    <meta type="array">
        <type>module</type>
        <description>Language labels for the extension</description>
    </meta>
    <data type="array">
        <languageKey index="default" type="array">
            <label index="error.email">your error message</label>
        </languageKey>
    </data>
</T3locallang>

Be free to experience what else is possible or necessary. If you want to have more than one error message translated I recommend you to extend the locallang key with the error code. Could be sth. like this:

<f:translate key="error.{field.propertyName}.{field.errorCode}" htmlEscape="false">Not translated: [{fieldError.message}]</f:translate>

<label index="error.email.1221559976">your error message</label>

Alright, that's it in the first place. Here is a list of all links I referred to in this post.

Useful links:

• http://wiki.typo3.org/Fluid
• blog_example
• class Tx_Extbase_MVC_Controller_ArgumentError
• class Tx_Extbase_Validation_PropertyError
• class Tx_Extbase_Error_Error

Found a mistake? Have a question? Offer critisism?
Just leave a reply!