ChangeLog for Extbase
=====================

Changes for 1.3.0:
==================
included in TYPO3 4.5.0 LTS.

This release fixes an important bug in the persistence layer, which caused related objects not to be updated.

Full Changes for 1.3.0:
=======================

[+BUGFIX] Extbase (Tests): reset added t3lib_div instances in UriBuilder & Extension tests
[+BUGFIX] Extbase (Persistence): Fixed updating of related objects. Thanks to Björn Steinbrück and Bastian Waidelich for digging into this issue. Resolves #9270, #9182, #10211.
	This is the second attempt after having reverted the first one in r3920. The patch includes some clean-up. Important additional changes:
	* The objects within an ObjectStorage are now added to the queue. This is necessary to persist changes made to those contained objects without having changed the composition of objects.
	* Moved the _memorizeCleanState() from the AbstractEntity to the AbstractDomainObject. In theory ValueObjects are immutable, but we need this as sometimes ValueObjects are stored in two steps (1. to get a UID, 2. to persist its properties). Maybe we have to recheck this for 1.4.
	* Fixed some possible problems with detecting an ObjectStorage (namely SplObjectStorage->getUid()).
[+TASK] Extbase (Persistence): Added two properties to describe a weird PHP behavior if calling current() on an ObjectStorage.
[+BUGFIX] Extbase (MVC): Fixed argument order of Tx_Extbase_Utility_Extension::isActionCacheable() call in UriBuilder
[+TASK] Extbase (DomainObject): Added setPid() and getPid() to the DomainObjectInterface and removed the "final" keyword.
[~TASK] Extbase: Moved isActionCacheable() from UriBuilder to Utility/Extension helper class
	Moved the protected method to a public static functions in Tx_Extbase_Utility_Extension
	and added respective unit tests.
	Note: We're not happy with all the public static functions in Utility/Extension.php
	but that's currently the place for those helper functions.
[+TASK] Extbase (Utility): implemented validation of arguments passed to sql statements in Tx_Extbase_Utility_Cache. (resolves #11978)

Changes for 1.3.0 RC1:
======================
included in TYPO3 4.5.0 RC1.

This release features many bugfixes, in the following areas:
* Persistence - invalid SQL has been fixed at various places
* MVC - the URI Builder can now handle cached / uncached actions correctly
* Improved error handling to catch some configuration errors
* Localization - TypoScript overrides for locallang keys with dot inside now works (_LOCAL_LANG.foo.bar)
* Persistence - added "pid" property and getter and setter to AbstractDomainModel; thus you can now move
  domain objects to different pages. However, this feature has *no support for workspaces* yet.
* Dependency Injection - now allows the injection of prototypes (see below)
* Configuration - for defining the Storage PID, one can use arbitary TypoScript objects (see below)

Dependency Injection Improvements
---------------------------------

Now, Prototype objects are allowed to be injected into other objects. This means the following cases
are supported:

* Singletons which need Singletons (most common)
* Singletons which need Prototypes (very uncommon,
  as it usually hints at the fact that the injected
  prototype should be a singleton). In this case,
  WE WRITE A DEVLOG MESSAGE
* Prototypes which need Singletons
* Prototypes which need Prototypes

TypoScript Storage PID Improvements
-----------------------------------

The persistence.storagePid now has stdWrap properties so the storagePid can be set dynamically.
Now follows an example for use in the Frontend:
	plugin.tx_extkey.persistence.storagePid.cObject = TEXT
	plugin.tx_extkey.persistence.storagePid.cObject.value = 8,3
... and this is how you can use it in the backend:
	module.tx_extkey.persistence.storagePid.cObject = TEXT
	module.tx_extkey.persistence.storagePid.cObject.value = 8,3

Full Changes for 1.3.0 RC1:
===========================
[+BUGFIX] Extbase (Object): constructor injection now works if default value for a dependency is NULL. Thanks to Lienhart Woitok! Resolves #11623
[+BUGFIX] Extbase (Object): Allow injection of prototypes via dependency injection. Resolves #12013
[+BUGFIX] Extbase (Persistence): Use sql_free_result() in Typo3DbBackend to free result memory. Resolves #10957
[~BUGFIX] Extbase (Persistence): fixed an wrong referenced exception (resolves #12403)
[~BUGFIX] Extbase (Persistence): make Tx_Extbase_Persistence_Repository::remove() handle freshly created objects right. (resolves #11128)
[+BUGFIX] Extbase (MVC): UriBuilder automatically added a cHash even on links to nonCacheable actions where this is not needed/recommended (resolves #8565)
[~BUGFIX] Extbase (Persistence): made union statement on comma seperated list use find_in_set (Thanks to Marc Bastian Heinrichs) (resolves #9772)
[~FOLLOWUP] Extbase (Utility): allow clearPageCache() to clear single, multiple and all pageCaches. (resolves 11978)
[+TASK] Extbase (Utility): allow clearPageCache() to clear single, multiple and all pageCaches.
[+BUGFIX] Extbase (MVC): Improve Error Handling in Request Builder. Resolves #11302
[+BUGFIX] Extbase (Persistence): remove superfluous require_once statements. Thanks to Oliver Klee. Resolves #12324
[+BUGFIX] Extbase (Tests): Remove require_once of phpunit testclasses. Thanks to Oliver Klee. Resolves #12323
[+BUGFIX] Extbase (Utility): Make _LOCAL_LANG override work with dots. Thanks to Thomas Maroschik. Resolves #12121
[+BUGFIX] Extbase (Persistence): Fixed using the correct columnname for contains comparison with RELATION_HAS_MANY and empty parentKeyFieldName. Resolves #11048
[+BUGFIX] Extbase (Persistence): Added the missing pid property to the AbstractDomainModel. Related to #11361
[+BUGFIX] Extbase (Persistence): Language Oberlay now works with page table as well. Thanks to Andre Stoesel. Resolves #11319
[+BUGFIX] Extbase (Persistence): The QueryObject gets cloned now in the getFirst() method of the QueryResult (as it was intended). Thanks to Sebastian Fischer. Resolves #11855.
[+BUGFIX] Extbase (Bootstrap): Bootstrap calls initialize on reflectionService if it's already initialized. Resolves #12346, resolves #12156
[+BUGFIX] Extbase (Persistence): Fix equals constraint with $caseSensitive FALSE (closing bracket missing). Thanks to Alexander Berl. Resolves #10781
[+BUGFIX] Extbase (Reflection): ObjectAccess::isPropertyGettable works for ArrayAccess objects. Resolves #10148
[+BUGFIX] Extbase (Configuration): Allow StoragePid to be manually defined by TS. Thanks to Rens Admiraal! Resolves #8397
[+BUGFIX] Extbase (Configuration): Fix warning in AbstractConfigurationManager. Resolves #11631
[+BUGFIX] Extbase (Object): Disabling Dependency Injection for injectSettings method. Resolves #11011


Changes for 1.3.0 Beta 4:
=========================
included in TYPO3 4.5.0 Beta 4.

This release contains numerous bugfixes, and a few small features:

* Tx_Extbase_Utility_Extension::registerPlugin() now has a fourth parameter $pluginIconPathAndFilename
  that you can set to the path of an icon, that will be displayed in the plugin dropdown in the backend.
  You can use it like:
  Tx_Extbase_Utility_Extension::registerPlugin(
		$_EXTKEY,
		'MyPlugin',
		'My Plugin description',
		t3lib_extMgm::extRelPath($_EXTKEY) . 'Resources/Public/Icons/someIcon.gif'
  );
* Hidden Records in Workspaces now work
  Before, if t3lib_pageSelect::getRecordOverlay returned FALSE (if
  no translation is found), a fatal error occured:
  PHP Catchable Fatal Error: Argument 2 passed to Tx_Extbase_Persistence_Mapper_DataMapper::getTargetType()
  must be an array, boolean given, called in Persistence/Mapper/DataMapper.php

Full Changes for 1.3.0 Beta 4:
==============================

[+TASK] Extbase (Tests): Fixed a repository unit test so that it works in CLI mode
[+TASK] Extbase (Tests): Fixed Extbase unit tests
[+BUGFIX] Extbase (Persistence): Hidden Records in Workspaces now work
[~TASK] Extbase: Fixed line endings (Windows to Unix).
[~TASK] Fluid (Tests): Fixed some more testcase class names and some unit tests
[+FEATURE] Extbase (Utility): Add support for custom specify custom plugin icon. Resolves #11179

Changes for 1.3.0 Beta 3:
=========================
included in TYPO3 4.5.0 Beta 3.

This release features numerous stability improvements, the biggest one
being a re-written core of the Object Manager, such that Lifecycle Methods
are supported now. This means, that a method "initializeObject()" gets called
as soon as all dependencies are injected and initialized.

Additionally, Extbase didn't work in all cases in the TYPO3 Backend. This has
also been improved, so Extbase (again) works in the backend
with an empty page tree.

Full Changes for 1.3.0 Beta 3:
=============================

[+BUGFIX] Extbase (Tests): Fixed Tx_Extbase_MVC_Controller_AbstractController_testcase. Thanks to Oliver Klee. Resolves #11567.
[BUGFIX] Extbase (Configuration): Make Extbase work again in Backend
[!!!][+TASK] Extbase (Object): Rewritten Object Container
[+BUGFIX] Extbase (MVC): Improve Exception message
	If one misses the @dontvalidate annotation, he will
	get a strange error which does not have a hint that
	the @dontvalidate is missing. Now, the exception message
	is extended.
[+API] Extbase (Configuration): Adding getContentObject to API
[+TASK] Extbase (Reflection): Added deprecation annotation to ObjectAccess::getAccessiblePropertyNames()
	To stay in sync with FLOW3, the methods getAccessibleProperties() and getAccessiblePropertyNames() to
	getGettableProperties() and getGettablePropertyNames().
	For compatibility reasons the old methods will stay in Extbase until version 1.5.
	Note: you can now check wheter properties are settable as well
[+FEATURE] Extbase (Reflection): Tx_Extbase_Reflection_ObjectAccess supports stdClass objects now
	I've backported the ObjectAccess class and its unit tests from FLOW3.
	Note: FLOW3's implementation allows to specify a third argument for the
	method getPropertyPath() in order to support Closures.
	This part is not backported as it's not compatible with PHP < 5.3.

Changes for 1.3.0 Beta 2a:
==========================
included in TYPO3 4.5.0 Beta 2.

This release includes a whole bunch of bugfixes and refactorings, the most important ones listed below.
Because the FlashMessages now use t3lib_FlashMessage, TYPO3 4.5 is MANDATORY!

The main changes are:

* Tx_Extbase_MVC_Controller_FlashMessages now internally uses the
  t3lib_FlashMessageQueue that has been introduced with TYPO3 4.3.
  This results in following changes:
  - flashmessages are now treated globally, not in a per-extension-scope. As soon as you output the messages first, the session will be flushed
  - a flashmessage is not a simple strings anymore, but consists of
    message body and (optionally) title & severity.
    You can specify title and severity like this:
    $this->flashMessages->add('Your message', 'some title', t3lib_FlashMessage::WARNING);
  - you can now output flashmessages in backend that were set from other TYPO3 classes
  - a revised flashmessage ViewHelper allows you to render flashmessages in the style
    of core flashmessages now (see Fluid changelog)
  - Resolves #10821
* Configuration Manager can now deal with recurring FlexForm Sections (#6067)
* Fixed Tx_Extbase_Domain_Model_FrontendUser (and marked the old API as deprecated)
* Bugfixes related to Lazy Loading

Full Changes for 1.3.0 Beta 2a:
==============================
[+BUGFIX] Extbase (Configuration): change the order of methods to determine the current pageId for backend modules, which is used to fetch the TS framework configuration. Fixes #11205
[+TASK] Extbase (Object): Make sure the class info cache is returning valid objects
[+BUGFIX] Extbase (Persistence): Persistence_Backend::getIdentifierByObject should work with LazyLoadingProxy
	getIdentifierByObject should check if object is an instance of Tx_Extbase_Persistence_LazyLoadingProxy and should return the
	identifier of the real object.
[+BUGFIX] Extbase (Configuration): slightly tweaked FrontendConfigurationManager (basically replaced explode() by t3lib_div::trimExplode() call)
[+TASK] Extbase (Tests): Added some unit tests for Backend- and FrontendConfigurationManager. To be continued
[+BUGFIX] Extbase (DomainObject): added default __toString method to Tx_Extbase_DomainObject_AbstractDomainObject. Thanks to Marco Huber. Resolves #8083
[+BUGFIX] Extbase (MVC): Fixed UriBuilder for handling LazyLoadingProxy objects as arguments. Resolves #10705
[+TASK] Extbase (Object): re-added Tx_Extbase_Object_Manager to gain more backwards compatibility. This class is marked deprecated and will be removed in Extbase 1.5
[+BUGFIX] Extbase (Tests): tweaked ObjectContainer tests. Tests are failing deliberately for now
	The DI implementation has to be rewritten, as discussed.
	This relates to: #11160
[+BUGFIX] Extbase (Domain): fixed (non-breaking) method name for getting usergroup in Tx_Extbase_Domain_Model_FrontendUser. Resolves #11019
[+TASK] extbase (ConfigurationManager): Made FrontendConfigurationManager parse recurring sections in flexforms right. Thanks to Franz Koch (resolves #6067)
[+BUGFIX] Extbase (Configuration): Slightly tweaked AbstractConfigurationManager
[+TASK] Extbase (Tests): Added unit tests for AbstractConfigurationManager
	Note: the ConfigurationManager now always overrides switchableControllerActions
	when retrieving configuration for the current plugin. Before that only happened
	when no extensionName/pluginName was specified.
	Additionally: It's not possible anymore to specify new controllers in
	switchableControllerAction configuration. That was the intended behavior.
[+TASK] Extbase (Tests): Renamed test files from "*_testcase.php" to "*Test.php"
[+TASK] Extbase (Tests): Moving all Tests in "Unit" directory.
[+FEATURE] Extbase (MVC): add possibility to output FlashMessageQueue (Resolves #10821)
[+TASK] Extbase (Persistence): counting query results does not work with limit constraints (resolves #10956)	Tx_Extbase_Persistence_Storage_Typo3DbBackend::getObjectCountByQuery() replaces the SELECT part
	of a query by COUNT(*) before executing a statement.
	This did not work as expected in some cases, e.g. the LIMIT constraint was ignored by the count query.
[+TASK] Extbase (Persistence): findOneBy*() methods should return NULL if no item was found (Resolves #10958)
[+TASK] Extbase (Core): Slightly improved error handling in bootstrap (Resolves #11055)
[~TASK] Extbase (Utility): Changed Tx_Extbase_Utility_TypoScript:convertPlainArrayToTypoScriptArray to self::convertPlainArrayToTypoScriptArray. Resolves #10538.
[+BUGFIX] Extbase (MVC): UriBuilder: use current plugin if no pluginName has been specified
	If multiple plugins are found, that are configured to handle the specified action, Extbase
	will throw an Exception. Now, this only happens if the *current* plugin does not contain
	the action.

Changes for 1.3.0 Beta 1a:
==========================
included in TYPO3 4.5.0 Beta 1.

Extbase 1.3.0 Beta 1 has a lot new and greatly improved features, and also many bugfixes.
The highlights are outlined below, and explained in-depth a little further down.

NOTE: This release brings new table definitions, so please visit the install tool or the Extension
Manager and update the tables of Extbase.

*** EVERY FEATURE IS DESCRIBED IN DEPTH BELOW ***

* Dependency Injection
* Dispatcher Refactoring & Completely re-done Configuration Manager
	This means that Tx_Extbase_Dispatcher is now DEPRECATED!
	Additionally, if you defined the TypoScript setup for a plugin by hand (which you should not),
	the syntax has changed a bit there.
* QueryResult refactoring (needed for Fluid Widgets)
	THIS COULD BE A BREAKING CHANGE FOR YOU!

Additionally, the following smaller features were implemented:

* Configurable plugin namespaces (#8365)
* Automatic target page determination (#9121)
* Improved resolveView() mechanism
* Allowing plugins to be registered as new content element (#10666)
* Default Orderings & QuerySettings (#10319)

Breaking Changes:

* The UriBuilder now uses the current cObject instead of creating a new instance in the constructor. This is a breaking change if you instantiated the UriBuilder in your code. Please use the Extbase ObjectManager or inject the ConfigurationManager manually.
* fixed typo in getter and setter of Tx_Extbase_Domain_Model_FrontendUser::lastlogin
* Flashmessages now share a scope throughout the extension. Before, every plugin had it's own scope leading to the messages only being output when entering the same plugin again (e.g. redirecting from one plugin to another would never display the messages)

Known issues:

* The Unit Tests do not fully work again, we will fix that in the next days.
* There might be still issues with the support of backend modules, we are working on that!

Dependency Injection
--------------------

Instead of creating objects through t3lib_div::makeInstance, and connecting them together manually,
you yan now use Dependency Injection (DI) for that. Let's give an example: If my class "Tx_Foo_Controller_MyController"
needs another class "Tx_Foo_Service_LoggingService", it can get an instance of the logging service
by Dependency Injection, by specifying the following code:

class Tx_Foo_Controller_MyController {
	protected $loggingService;

	/**
	 * @param Tx_Foo_Service_LoggingService $loggingService
	 */
	public function injectLoggingService(Tx_Foo_Service_LoggingService $loggingService) {
		$this->loggingService = $loggingService;
	}
}

The DI container finds that the class "MyController" has an method whose name starts with "inject",
and thus passes the logging service to MyController.
It is important that you can *only retrieve Singletons* through the inject annotations. If you need
to instanciate a prototype object, it is important to *not* use t3lib_div::makeInstance() anymore
(as it bypasses the DI container), but instead you need to inject the ObjectManager, and ask it
to create your prototype object using the create() method. Example:

class Tx_Foo_Controller_MyController {
	protected $logFile;

	/**
	 * @param Tx_Extbase_Object_ObjectManagerInterface $objectManager
	 */
	public function injectObjectManager(Tx_Extbase_Object_ObjectManagerInterface $objectManager) {
		$this->logFile = $objectManager->create('Tx_Foo_Domain_Model_LogFile');
	}
}

In the above example, you have seen that we reference not the concrete implementation *ObjectManager*,
but instead the *ObjectManagerInterface*. If a name ends with "...Interface", Extbase DI automatically
strips away the "Interface" from the name, and expects to find a concrete implementation of that interface.
This is generally a very good practice: For your core classes, you should always reference an *interface*,
and let the DI container instanciate the concrete class.

Additionally, Extbase DI allows to *replace* certain implementation classes by other classes through
configuration in TypoScript. Let's give an example, and then you can see the concept:

config.tx_extbase.objects {
	Tx_Extbase_Persistence_Storage_BackendInterface {
		className = Tx_Extbase_Persistence_Storage_Typo3DbBackend
	}
}

This essentially means to the DI container: "At all places where you encounter a "BackendInterface",
you should instanciate the "Typo3DbBackend" class."

However, note that this setting can only be configured *globally* right now, it is not possible
to override that on a per-extension basis.

Generally, the Extbase DI container provides a subset of the functionality of FLOW3's dependency injection.

Dispatcher Refactoring & Completely re-done Configuration Manager
-----------------------------------------------------------------

In the last versions of Extbase, the Dispatcher (Tx_Extbase_Dispatcher) was the main entry point to Extbase.
However, as we did not have Dependency Injection at that point, it became really complex and did lots of things
which it should not do in the first place. That's why we greatly improved that part. Now, any Extbase extension
is invoked using the Tx_Extbase_Core_Bootstrap. Additionally, the TypoScript used for the registration of any
Extbase extension has been cleaned up and adjusted:

lib.foo = USER
lib.foo {
	userFunc = tx_extbase_core_bootstrap->run
	extensionName = YourExtension
	pluginName = YourPlugin
}

Additionally, you can also override the list of Switchable Controller Actions through TypoScript:

lib.foo = USER
lib.foo {
	userFunc = tx_extbase_core_bootstrap->run
	extensionName = YourExtension
	pluginName = YourPlugin
	switchableControllerActions {
		Standard {
			1 = action2
			2 = action3
		}
	}
}

Of course, you cannot call actions which were not defined previously in the plugin; so the Switchable
Controller Actions in TypoScript can be only used to shrink the number of actions available.

NOTE: If you manually defined the above snippet, notice that there is a NON-BACKWARDS-COMPATIBLE change
in there. But you did that at your own risk, as that was never public API ;)

If you used Tx_Extbase_Dispatcher before in your own code, it should still work, but it is deprecated.
Instead, instead

OLD: Tx_Extbase_Dispatcher::getConfigurationManager()
NEW: inject Tx_Extbase_Configuration_ConfigurationManagerInterface into your class

OLD: Tx_Extbase_Dispatcher::getPersistenceManager()
NEW: inject Tx_Extbase_Persistence_ManagerInterface into your class

OLD: Tx_Extbase_Dispatcher::getExtbaseFrameworkConfiguration()
NEW: inject Tx_Extbase_Configuration_ConfigurationManagerInterface into your class,
     and call $configurationManager->getConfiguration(Tx_Extbase_Configuration_ConfigurationManagerInterface::CONFIGURATION_TYPE_FRAMEWORK);
     on the ConfigurationManager.

Please note that the Configuration Manager is STILL NO PUBLIC API, and its method signature has also changed.

QueryResult refactoring (needed for Fluid Widgets)
--------------------------------------------------

Before this change, a call of $query->execute() inside a repository immediately executed the query and
returned the result as array.
Now, queries are executed lazily at the first moment where you really need them. This means that $query->execute()
returns an object of type Tx_Extbase_Persistence_QueryResultInterface, which behaves like an array, meaning you
can use foreach() to loop over the query result.
However, due to an inconsistency of PHP, the array_* methods, and the iteration methods like current(),
next(), ... do NOT work on objects which implement ArrayAccess -- that's the reason why the QueryResult
refactoring is a breaking change.

Now, however, the following is possible:
* Return the first query result: $query->execute()->getFirst()
* Get the underlying query: $query->execute()->getQuery()
* Convert the result to array: $query->execute()->toArray()

This change is a prerequisite for Fluid Widgets to work. See the Fluid ChangeLog for details.


Configurable Plugin Namespaces
------------------------------

By default each Extbase plugin has a unique URI prefix to avoid collisions with other plugins on your website.
This so called plugin namespace usually has the format tx_yourextension_yourplugin.
With Extbase 1.3 it is possible to override this namespace. This comes in handy if want to interact with 3rd party
extensions, for example with tt_news:

plugin.tx_yourextension.view.pluginNamespace = tx_ttnews

This sets the plugin namespace of all your plugins inside the extension to "tx_ttnews", making it possibl
to directly access tt_news parameters in your controller:

/**
 * @param integer $tt_news tt_news Article uid
 * @return void
 */
public function yourAction($tt_news) {
	// interact with $tt_news uid
}

This works with automatic mapping to Domain models too of course:

/**
 * @param Tx_YourExtension_Domain_Model_NewsArticle $tt_news tt_news Article
 * @return void
 */
public function yourAction(Tx_YourExtension_Domain_Model_NewsArticle $tt_news) {
	// interact with $tt_news object
}

You can also override the plugin namespace for a single instance by adding the section <view.pluginNamespace> to your
plugin FlexForm.


Automatic target page determination
-----------------------------------

In TYPO3 v5 we won't have the notion of page uids. To accustom developers to this change, we're trying to free you from
the need to specify target pages from within your Extension. Of course you can put all your functionality into one fully
fledged plugin, then you won't have to deal with target pages as the current page is used by default.

But sometimes you want to be able to change the surrounding contents of a special view of your extension (e.g. the
subcontent column of a details page). As before you can still specify the target page explicitly like:

<f:link.action action="foo" pageUid="123" />

With Extbase 1.3 you can also use a new feature called "automatic target page determination". It is disabled by default,
but you can enable it with the following TypoScript:

plugin.tx_yourextension.view.defaultPid = auto

Then Extbase will search the page tree for a plugin that is configured to handle the specified action and you can omit
the "pageUid" parameter in your links. Of course, this does not work if you use the same plugin multiple times in your
page tree. In this case you can override the default page ID for the respective plugins:

plugin.tx_yourextension_yourplugin.view.defaultPid = 123

Note: By default this feature is not activated, because that would be a breaking change in some cases


Improved resolveView() mechanism
--------------------------------

Another feature we backported from FLOW3 is the improved view resolving.
You can now change the default view implementation *per format* by inserting the following line in your Controller:

protected $viewFormatToObjectNameMap = array(
	'json' => 'Tx_YourExtension_View_JsonView',
	'html' => 'Tx_YourExtension_View_HtmlView'
);


Allowing plugins to be registered as new content element
--------------------------------------------------------

This is done using an additional parameter to Tx_Extbase_Utility_Extension::configurePlugin
that allows you to specify the plugin type. Example:

Tx_Extbase_Utility_Extension::configurePlugin(
	$_EXTKEY,
	'BlogList',
	array('Blog' => 'index'),
	array(),
	Tx_Extbase_Utility_Extension::PLUGIN_TYPE_CONTENT_ELEMENT
);
(The default value for the pluginType parameter is Tx_Extbase_Utility_Extension::PLUGIN_TYPE_PLUGIN)

Default Orderings & QuerySettings
---------------------------------

It is now possible to change the default orderings of a repository without you having to modify the query by setting
the $defaultOrderings property of your Repository to a non-empty array:

protected $defaultOrderings = array(
	'title' => Tx_Extbase_Persistence_QueryInterface::ORDER_ASCENDING,
	'date' => 'title' => Tx_Extbase_Persistence_QueryInterface::ORDER_DESCENDING
);

This will change the default ordering for all queries created by this repository. Of course you can override the
ordering by calling $query->setOrderings() in your custom finder method.

Besides it's now possible to change the default query settings of a repository. This way you could for instance disable
"respect storage pid" for all queries. We added a life-cycle method "initializeObject" to the repository which will be
executed as soon as the repository is created. Just override it like the following:

public function initializeObject() {
	$querySettings = $this->objectManager->create('Tx_Extbase_Persistence_Typo3QuerySettings');
	$querySettings->setRespectStoragePage(FALSE);
	$this->setDefaultQuerySettings($querySettings);
}

Of course, QuerySettings can be overridden too in your custom finder method by calling $query->setQuerySettings();


Full Changes for 1.3.0 Beta 1a:
===============================
[+TASK] Extbase: Re-implement support for BE modules
[+FEATURE] Extbase (Utility): Allow plugins to be registered as new content element
	Added a fifth parameter to Tx_Extbase_Utility_Extension::configurePlugin that allows
	you to specify the plugin type (currently "list_type" and "CType" are supported).
	Thanks to Marc Bastian Heinrichs, Rens Admiraal & Franz Koch for your help!
	Resolves: #10666
[+BUGFIX] Extbase (Utility): Added condition to Tx_Extbase_Utility_Extension::getTargetPidByPlugin() in order to only select tt_content entries that are of CType "list". Thanks to Marc Bastian Heinrichs
[!!!][~TASK] Extbase (Configuration): Major rework of the ConfigurationManager
	Configuration of controllers and actions is now stored in a global registry
	($GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['extbase']['extensions']). But you
	should never access this directly. Instead always retrieve the frameworkConfiguration
	from the ConfigurationManager.
	Inserting an Extbase plugin is now as simple as:
	lib.foo = USER
	lib.foo {
	  userFunc = tx_extbase_core_bootstrap->run
	  extensionName = YourExtension
	  pluginName = YourPlugin
	}
	This is not really a breaking change as it does not change the public API. But it's not unlikely that it changes the behavior of your Extension in case you modified the TypoScript, that is generated by Tx_Extbase_Utility_Extension::configurePlugin().
	NOTE: Unit tests of Extbase and Fluid v4 are broken currently. We'll be fixing those asap
[~TAKS] Extbase (MVC): FrontendRequestHandler now retrieves the current cObject through the ConfigurationManager
[+BUGFIX] Extbase (MVC): FrontendRequestHandler was refering to $this->frameworkConfiguration which wasn't available
[-API] Extbase (MVC): marked Tx_Extbase_MVC_Web_Request::getContentObjectData() deprecated as should retrieve the current cObject through the ConfigurationManager
[+TASK] Extbase (MVC): modified the Tx_Extbase_MVC_Web_RequestBuilder so that it's possible to change the action only by specifying the action parameter. Before you had to specify the controller as well, even if it was the default controller
[+BUGFIX] Extbase (MVC): Flashmessages now share a scope throughout the extension. Before, every plugin had it's own scope leading to the messages only being output when entering the same plugin again (e.g. redirecting from one plugin to another would never display the messages)
[~TASK] Extbase (Core): The Flashmessages now get persisted in the Bootstrap in resetSingletons()
[-TASK] Extbase (Core): Removed some commented lines from Bootstrap
[FEATURE] Extbase (Object): Make DI Class Mapping configurable through TS
	It is now possible to configure the Dependency Injection class mapping by specifying:
	config.tx_extbase.objects.[FullyQualifiedObjectName].className = [NewClassName]
	This has the effect of effectively replacing [FullyQualifiedObjectName] with
	[NewClassName].
	Resolves: #10559
[-TASK] Extbase (Utility): Removed two obsolete checks for $GLOBALS['TSFE']->tmpl->setup['tt_content.']['list.']['20.'] in Tx_Extbase_Utility_Extension
[~TASK] Extbase: added two doc comments that were missing
[+BUGFIX] Extbase (Persistence): Extbase still used PHPs current() on some QueryResults in Persistence/Repository. Replaced these by calls to the getFirst() method of the QueryResult
[+TASK] Extbase (Persistence): added a private field to the QueryResult to make the above case easier to debug: When calling current() on an Iterator, PHP returns the first field of that object instead of calling the current() method of the Iterator interface.. With our somewhat pragmatic approach you'll see the warning if you debug the results of current($query->execute())
[+BUGFIX] Extbase (Persistence): Replaced two occurrences of Query->count() by Query->execute()->count() to avoid deprecated warnings in the Core
[+BUGFIX] Extbase (MVC): view configuration (templateRootPath, ...) has to be set before View::canRender() is called
[!!!][+TASK] Extbase (MVC): The UriBuilder now uses the current cObject instead of creating a new instance in the constructor. This is a breaking change if you instantiated the UriBuilder in your code. Please use the Extbase ObjectManager or inject the ConfigurationManager manually.
[+BUGFIX] Extbase (Reflection): ReflectionService now uses a cacheIdentifier per Extension. Besides the Bootstrap now resets the ReflectionService after dispatching a request. This resolves #10146
[+TASK] Extbase (Configuration): The ConfigurationManager now holds the current cObject. You can retrieve it via ConfigurationManagerInterface::getContentObject()
[+BUGFIX] Extbase (Configuration): When loading configuration of other plugins, the context specific configuration (e.g. flexform settings) are no longer merged with the frameworkConfiguration
[+BUGFIX] Extbase (MVC): Controllers are no Singletons by default. If a controller contains stateful fields (e.g. $this->settings) this breaks multiple plugins on one page
[+TASK] Extbase (Persistence): QuerySettings now also store the storage page id(s). This is required for the upcoming Ajax Widgets
[+BUGFIX] Extbase: fixed php warning in Tx_Extbase_Persistence_LazyLoadingProxy when loading the real instance would return NULL. Resolves #10683
[+BUGFIX] Extbase: use 3rd parameter = TRUE of t3lib_div::trimExplode to split switchableControllerActionParts from flexform. Thanks to Georg Ringer. Resolves #10688
[+TASK] Extbase: Replaced "public static" by "static public" in various places to be CGL conform
[+TASK] Extbase: Marked Utitlity_Extension camelCase/underscore helper functions deprecated
[+TASK] Extbase: Removed obsolete FIXME comments, whitespace fixes
[!!!] Extbase: Reintegrating branch "dispatcher" to trunk. Resolves: #10605
	Branch history:
[+FEATURE] Extbase (Configuration): Extend ConfigurationManager so that it can load configuration of different plugins
[+FEATURE] Extbase (Configuration): 1st level cache for ConfigurationManager. Resolves: #10717. Resolves: #10716
[+TASK] Extbase: cleaned up Configuration* implementation, replaced t3lib_div::makeInstance() calls
	Streamlined ConfigurationManager API and enforced its usage throughout the Extbase classes.
	Replaced all t3lib_div::makeInstance() calls by $objectManager->create()/$objectManager->get() throughout the Extbase classes.
	Some smaller tweaks and fixes. Resolves: #10655. Resolves: #10712
[TASK] Extbase (Object): Make tests work again. Resolves: #10709
[TASK] Extbase (Object): Updated autoload.php and emconf. Relates to: #10561
[TASK] Extbase (Object): Use typed exceptions. Relates to: #10561
[TASK] Extbase (Object): CGL cleanup
	Additionally, removed support for @inject annotations at methods. Relates to: #10561
[TASK] Extbase (Object): Remove getParents. Relates to: #10561
[TASK] Extbase (Object): Remove isSingleton. Relates to: #10561
[TASK] Extbase (Object): Remove injectExtensionSettings feature. Relates to: #10561
[TASK] Extbase (Object): Change namespaces to Tx_Extbase_Object_Container. Relates to: #10561
[TASK] Extbase (Object): Add Container to Extbase. Relates to: #10561
[+TASK] Extbase (Core): moved Tx_Extbase_Bootstrap to Tx_Extbase_Core_Bootstrap
	Moving Bootstrap to be compliant with FLOW3
	Removed obsolete Classes. Resolves: #10704
[+TASK] Extbase: Merged current trunk (r2689) with local modifications into dispatcher branch
	Note: This still needs a cleanup and some fixes (see FIXME comments) before it can be merged back to the trunk. Relates to: #10605. Relates to: #10655
[+TASK] Extbase (Configuration): Moved CONFIGURATION_TYPE_* constraints to ConfigurationManagerInterface. Resolves #10604.
[~TASK] Extbase (Configuration): The concrete configuration management strategy gets instanciate only once now.
[+FEATURE] Extbase (MVC): Decoupled framework settings from Dispatcher.
	With the new dependency injection feature you can get the Configuration Manager injected by adding the lines
	protected $configurationManager;
	public function injectConfigurationManager(Tx_Extbase_Configuration_ConfigurationManagerInterface $configurationManager) {
		$this->configurationManager = $configurationManager;
	}
	You can get various types of configuration invoking
	$this->configurationManager->getConfiguration(Tx_Extbase_Configuration_ConfigurationManager::CONFIGURATION_TYPE_EXTBASE)
	where the class constant must be either CONFIGURATION_TYPE_EXTBASE (for Extbase settings), or CONFIGURATION_TYPE_SETTINGS (for the current module/plugin settings), or CONFIGURATION_TYPE_TYPOSCRIPT (for a raw TS array). Resolves #4741.
[~TAKS] Extbase: Removed obsolete code.
[~TASK] Extbase: Added core patch for mod.php (see previous commit).
[+TASK] Extbase: Changed the way a module gets called.
	- You can now specify a function name to be invoked by mod.php:
$TBE_MODULES['_dispatcher'][] = 'Tx_Extbase_Bootstrap->callModule';
	- This requires a core patch.
[~TASK] Extbase: Changed configuration of the RequestHandler class names to TypoScript.
	- The request handlers can now be registered in TypoScript with the setting:
	   config.tx_extbase.mvc.requestHandlers.[RequestHandlerClassName] = [RequestHandlerClassName].
	- There are now two RequestHandlers in Extbase: FrontendRequestHandler and BackendRequestHandler. Common functionality is in the AbstractRequestHandler.
[+API][+FEATURE] Extbase (Utility): Implemented mechanism to register RequestHandlers.
[+TASK] Extbase: Backported Request Handler Resolver.
[~TASK] Extbase: Added "deprecated" annotation to Dispatcher.
[~TASK] Extbase: Added missing comment.
[+BUGFIX] Extbase (Reflection): The ReflectionService now gets injected to the dispatcher. Related to #10146.
[+BUGFIX] Extbase (Reflection): Changed the way the Reflection Service and it's cache gets initialized.
	* Removed check for pre-initialized Reflection Service in the Bootstrap.
	* Now using a fixed cache key ('ReflectionData').
	Related to #10146.
[~TASK] Extbase: First step of the Dispatcher refactoring.
	* Added and adapted some Unit Tests.
	* Moved the Dispatcher to MVC.
	* Added a backwards compatibility Dispatcher on root level.
	* Added a Bootstrap class.
	* Removed all backend module support for now.
	Related to #7153.
[+TASK] Extbase: Added branch for the dispatcher refactoring.
[!!!][+BUGFIX] Extbase: fixed typo in getter and setter of Tx_Extbase_Domain_Model_FrontendUser::lastlogin . Thanks to Christian Schwan. Resolves #9345
[+FEATURE] Extbase (MVC): Backport possibility to change the view object class name more easily
	Backported FLOW3s improved resolveView() mechanism. Tx_Fluid_View_TemplateView is still the default implementation, but can be easily changed by setting $defaultViewObjectName in your controller. Besides it's possible to specifying different views depending on the current request format by setting $viewFormatToObjectNameMap.
	NOTE: If the view can't be rendered, the new template based "NotFoundView" will be created. So instead of the invisible HTML comments of the EmptyView, you'll get a more meaningful error message if the template file could not be found
	Resolves: #8990
[!!!][+FEATURE] Extbase (Persistence): Backport QueryResult from FLOW3
	Now Query::execute() returns an instance of QueryResultInterface that allows it to modify the query before actually accessing the records that it retrieves. This is required for the upcoming "Fluid widgets" backport (#10568).
	NOTE: This change is not backwards compatible, if you work with PHPs array_* functions on the query result. To work around this issue, you'll have to convert the query result to an array before by calling the QueryResult::toArray() method. We're planning to add a compatibility mode, but that's not yet implemented.
	Resolves: #10566
[+BUGFIX] Extbase (Object): Minor fix in ObjectManager to make it compatible with PHP 5.2.x
	Relates to: #9062
[+BUGFIX] Extbase (Object): Refactor Object Manager
	The Object Manager is now at the same location and
	has the same API as in FLOW3.
[+BUGFIX] Extbase: Major cleanups to Dependency Injection and Persistence
	Now, DI finally works with Persistence, cleaning
	this greatly up. Additionally, all internal
	t3lib_div::makeInstance calls have been replaced.
	Now, dependency injection is actually usable.
	Additionally, we completely thought over which
	persistence classes need to be singleton and which
	should be prototype, leading finally to a
	coherent design in the persistence layer.
[+BUGFIX] Extbase: remove non-used interfaces
	Removed classes which were not used.
	Relates to: #9062
	Resolves: #10585
	Resolves: #10564
	* Cleaned up Persistence Backend
	* Cleaned up QOM Factory
[+BUGFIX] Extbase (MVC): Fix arguments object
	The arguments object is now correctly inheriting from ArrayObject
	Resolves: #10562
[+BUGFIX] Extbase (MVC): Make database connection work again
	Resolves: #10585
[+FEATURE] Extbase (DI): merging DI into trunk. (resolves #10558)
[+TASK] Extbase: Undefined identifier in Tx_Extbase_Persistence_Storage_Typo3DbBackend::removeRow
	Method clearPageCache was given an undefined variable $uid as second parameter.
	Resolves: #10570
[+TASK] Extbase: $query->contains generate incomplete SQL
	Use FIND_IN_SET instead of a self-constructed query of LIKE statements
	Resolves: #8959
[+BUGFIX] Extbase (Persistence): Removed method createQuery from the QOMFactory. It is neither part of the API nor is it used by Extbase. Resolves #10215
[+BUGFIX] Extbase (Property): Minor fix in PHP doc comment
	Fix the order of @param annotation in Tx_Extbase_Property_Mapper::mapAndValidate()
	Resolves: #5887
[~CONFIGURATION] Extbase (MVC): Changed default value for automatic target page determination
	The page id gets automatically detected if plugin.tx_extensionname_pluginname.view.defaultPid
	is an empty string (was "auto" before). This ensures backwards compatibility.
	Resolves #9121
[TASK] Extbase: moved Release Notes to ChangeLog.txt.
[+FEATURE] Extbase (MVC): Automatic target page determination
	you can use the "pageUid" argument of the link.* and uri.* view helpers
	to link to a different page. That is deprecated though as we won't have
	the notion of "page uids" in v5. Instead the target page is now determined
	automatically.
	If the target page can't be determined because more than one active
	plugin is capable of handling the action an exception will be thrown.
	In that case you'll have to define the target page either by using the
	pageUid argument or - preferably - by setting
	plugin.tx_extensionname_pluginname.view.defaultPid to a fixed page uid.
	Note: This feature still has to be documented!
	Resolves: #9121
[+FEATURE] Extbase (MVC): Configurable plugin namespace
	until now the namespace (aka prefix) of Extbase plugins was
	fixed (tx_extensionname_pluginname). This is now configurable
	via TypoScript. Just write:
	plugin.tx_extensionname_pluginname.view.pluginNamespace = my_custom_namespace
	to change the prefix for a specific plugin or
	plugin.tx_extensionname.view.pluginNamespace = my_custom_namespace
	to change if for the whole extension.
	Note: This feature still has to be documented!
	Resolves: #8365

Changes for 1.3.0 Alpha 2:
==========================
included in TYPO3 4.5.0 Alpha 2.

Since the last version, one (possible BREAKING) change happened:

 * Fixed Extbase Caching Bug.
   Non-cacheable actions were cached due to the fact that TYPO3s
   TypoScript condition "GP" does not merge GET & POST vars.
   Additionally "switchableControllerActions" that were overridden
   in the plugin flexform were not taken into account.

!!! This is a breaking change if you set up your TS configuration
    of the plugin manually.

Full Changes:
-------------

[!!!][+BUGFIX] Extbase: Fix Extbase Caching Bug (thanks to Bastian Waidelich)

[-TASK] Extbase (MVC): removed fallback to current page in AbstractController::redirect() as that's already done within the UriBuilder if $targetPageUid is NULL


Changes for 1.3.0 Alpha 1:
==========================
included in TYPO3 4.5.0 Alpha 1.

Since the last version, the following notable things happened:

* All methods trying to find an object by uid now ignore the storagePid. This changes the behavior of argument mapping and the way extbase fetches 1:1 relations. Resolves #5631. You should not experience any negative side-effects of this change, i.e. if your extension worked before, it will definitely after this change. However, it makes the record handling more robust.
* Performance improvements in TypoScript::convertTypoScriptArrayToPlainArray. Thanks to Timo Schmidt.
* Numerous other bugfixes, see below.

Full Changes:
-------------
[~TASK] Extbase: Raised version number to 1.3.0-devel to reflect the version scheme defined in the wiki. Resolves #9152. Thanks Xavier for pointing to it.
[+TASK] Extbase (MVC): cleaned up View implementations and added assign() and assignMultiple() methods to ViewInterface. This resolves #9137
[+BUGFIX] Extbase: Fixed a small typo in extension description.
[+BUGFIX] Extbase (Persistence): DataMapper now mapps NULL into a property on non-existing related object instead of FALSE. Resolves #8973.
[+BUGFIX] Extbase (Reflection): getParentClass() in Tx_Extbase_Reflection_ClassReflection no longer causes a fatal error if no parent class exists. Resolves #8800.
[+BUGFIX] Extbase (Utility): Improved performance of TypoScript::convertTypoScriptArrayToPlainArray. Thanks to Timo Schmidt. Resolves #8857.
[~TASK] Extbase: Changed state to 'stable'. Resolves #8768.
[+BUGFIX] Extbase: Fixed EOL and encoding of several files. Resolves #8876.
[+BUGFIX] Extbase (MVC): Fixed a problem where a non-required action argument throwed Exception if it was not found in the Backend. Thanks to Marc Bastian Heinrichs. Resolves #7277.
[!!!][+BUGFIX] Extbase (Persistence): All methods trying to find an object by uid now ignores the storagePid. This changes the behavior of argument mapping and the way extbase fetches 1:1 relations. Resolves #5631.
[+BUGFIX] Extbase (Persistence): Fixed a problem where localized objects inside an aggregate are not translated. Resolves #8555.
[~TASK] Extbase: Removed new lines at the end of php files.

RELEASE NOTES of Extbase v1.0.0
===============================

This package contains the Extbase Framework for Extensions. You may
also want to install the BlogExample (blog_example) to experiment
with. This little example extension demonstrates some of the main
features of Extbase. The documentation is bundled in a separate
extension called doc_extbase. Both, the blog_example and the
doc_extbase can downloaded via TER.

http://typo3.org/extensions/repository/view/blog_example/current/
http://typo3.org/extensions/repository/view/doc_extbase/current/

Currently Extbase is in ALPHA state. Do not expect everything in the
right place and shape. And keep in mind that the API may change
until TYPO3 v4.3beta1 is released.

If you have any feature requests or encountered issues regarding
this package please use the facilities on forge to report.

We are very open to answer your questions. Please use the newsgroup

typo3.projects.typo3v4mvc on lists.netfielders.de

so other developers can react to your comments and also
profit from the postet solutions. Do not contact a member of the
development team via private email (or skype, or visits, or ...)
until he accepted this channel. We all do coding for Extbase on
our sparetime and must handle our regular work load - and don't
forget about our families ;-).

We hope you have fun with this package!

-- Your Extbase Development Team

HOW TO CREATE THE CHANGELOG
===========================
git log [startRevision]..HEAD --pretty=format:"%s%n%b%n" | grep -v "^$" | grep -v "git-svn-id"

Verify that the merge into the Core succeeded:
diff -urNw --exclude=".git" --exclude=".svn" -I "@version"  ../../../typo3/sysext/extbase/ .
