* Raising version to Extbase 1.3beta2a
[Packages/TYPO3.CMS.git] / typo3 / sysext / extbase / ChangeLog.txt
1 ChangeLog for Extbase
2 =====================
4 Changes for 1.3.0 Beta 2a:
5 ==========================
6 included in TYPO3 4.5.0 Beta 2.
8 This release includes a whole bunch of bugfixes and refactorings, the most important ones listed below.
9 Because the FlashMessages now use t3lib_FlashMessage, TYPO3 4.5 is MANDATORY!
11 The main changes are:
13 * Tx_Extbase_MVC_Controller_FlashMessages now internally uses the
14 t3lib_FlashMessageQueue that has been introduced with TYPO3 4.3.
15 This results in following changes:
16 - flashmessages are now treated globally, not in a per-extension-scope. As soon as you output the messages first, the session will be flushed
17 - a flashmessage is not a simple strings anymore, but consists of
18 message body and (optionally) title & severity.
19 You can specify title and severity like this:
20 $this->flashMessages->add('Your message', 'some title', t3lib_FlashMessage::WARNING);
21 - you can now output flashmessages in backend that were set from other TYPO3 classes
22 - a revised flashmessage ViewHelper allows you to render flashmessages in the style
23 of core flashmessages now (see Fluid changelog)
24 - Resolves #10821
25 * Configuration Manager can now deal with recurring FlexForm Sections (#6067)
26 * Fixed Tx_Extbase_Domain_Model_FrontendUser (and marked the old API as deprecated)
27 * Bugfixes related to Lazy Loading
29 Full Changes for 1.3.0 Beta 2a:
30 ==============================
31 [+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
32 [+TASK] Extbase (Object): Make sure the class info cache is returning valid objects
33 [+BUGFIX] Extbase (Persistence): Persistence_Backend::getIdentifierByObject should work with LazyLoadingProxy
34 getIdentifierByObject should check if object is an instance of Tx_Extbase_Persistence_LazyLoadingProxy and should return the
35 identifier of the real object.
36 [+BUGFIX] Extbase (Configuration): slightly tweaked FrontendConfigurationManager (basically replaced explode() by t3lib_div::trimExplode() call)
37 [+TASK] Extbase (Tests): Added some unit tests for Backend- and FrontendConfigurationManager. To be continued
38 [+BUGFIX] Extbase (DomainObject): added default __toString method to Tx_Extbase_DomainObject_AbstractDomainObject. Thanks to Marco Huber. Resolves #8083
39 [+BUGFIX] Extbase (MVC): Fixed UriBuilder for handling LazyLoadingProxy objects as arguments. Resolves #10705
40 [+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
41 [+BUGFIX] Extbase (Tests): tweaked ObjectContainer tests. Tests are failing deliberately for now
42 The DI implementation has to be rewritten, as discussed.
43 This relates to: #11160
44 [+BUGFIX] Extbase (Domain): fixed (non-breaking) method name for getting usergroup in Tx_Extbase_Domain_Model_FrontendUser. Resolves #11019
45 [+TASK] extbase (ConfigurationManager): Made FrontendConfigurationManager parse recurring sections in flexforms right. Thanks to Franz Koch (resolves #6067)
46 [+BUGFIX] Extbase (Configuration): Slightly tweaked AbstractConfigurationManager
47 [+TASK] Extbase (Tests): Added unit tests for AbstractConfigurationManager
48 Note: the ConfigurationManager now always overrides switchableControllerActions
49 when retrieving configuration for the current plugin. Before that only happened
50 when no extensionName/pluginName was specified.
51 Additionally: It's not possible anymore to specify new controllers in
52 switchableControllerAction configuration. That was the intended behavior.
53 [+TASK] Extbase (Tests): Renamed test files from "*_testcase.php" to "*Test.php"
54 [+TASK] Extbase (Tests): Moving all Tests in "Unit" directory.
55 [+FEATURE] Extbase (MVC): add possibility to output FlashMessageQueue (Resolves #10821)
56 [+TASK] Extbase (Persistence): counting query results does not work with limit constraints (resolves #10956) Tx_Extbase_Persistence_Storage_Typo3DbBackend::getObjectCountByQuery() replaces the SELECT part
57 of a query by COUNT(*) before executing a statement.
58 This did not work as expected in some cases, e.g. the LIMIT constraint was ignored by the count query.
59 [+TASK] Extbase (Persistence): findOneBy*() methods should return NULL if no item was found (Resolves #10958)
60 [+TASK] Extbase (Core): Slightly improved error handling in bootstrap (Resolves #11055)
61 [~TASK] Extbase (Utility): Changed Tx_Extbase_Utility_TypoScript:convertPlainArrayToTypoScriptArray to self::convertPlainArrayToTypoScriptArray. Resolves #10538.
62 [+BUGFIX] Extbase (MVC): UriBuilder: use current plugin if no pluginName has been specified
63 If multiple plugins are found, that are configured to handle the specified action, Extbase
64 will throw an Exception. Now, this only happens if the *current* plugin does not contain
65 the action.
67 Changes for 1.3.0 Beta 1a:
68 ==========================
69 included in TYPO3 4.5.0 Beta 1.
71 Extbase 1.3.0 Beta 1 has a lot new and greatly improved features, and also many bugfixes.
72 The highlights are outlined below, and explained in-depth a little further down.
74 NOTE: This release brings new table definitions, so please visit the install tool or the Extension
75 Manager and update the tables of Extbase.
79 * Dependency Injection
80 * Dispatcher Refactoring & Completely re-done Configuration Manager
81 This means that Tx_Extbase_Dispatcher is now DEPRECATED!
82 Additionally, if you defined the TypoScript setup for a plugin by hand (which you should not),
83 the syntax has changed a bit there.
84 * QueryResult refactoring (needed for Fluid Widgets)
87 Additionally, the following smaller features were implemented:
89 * Configurable plugin namespaces (#8365)
90 * Automatic target page determination (#9121)
91 * Improved resolveView() mechanism
92 * Allowing plugins to be registered as new content element (#10666)
93 * Default Orderings & QuerySettings (#10319)
95 Breaking Changes:
97 * 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.
98 * fixed typo in getter and setter of Tx_Extbase_Domain_Model_FrontendUser::lastlogin
99 * 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)
101 Known issues:
103 * The Unit Tests do not fully work again, we will fix that in the next days.
104 * There might be still issues with the support of backend modules, we are working on that!
106 Dependency Injection
107 --------------------
109 Instead of creating objects through t3lib_div::makeInstance, and connecting them together manually,
110 you yan now use Dependency Injection (DI) for that. Let's give an example: If my class "Tx_Foo_Controller_MyController"
111 needs another class "Tx_Foo_Service_LoggingService", it can get an instance of the logging service
112 by Dependency Injection, by specifying the following code:
114 class Tx_Foo_Controller_MyController {
115 protected $loggingService;
117 /**
118 * @param Tx_Foo_Service_LoggingService $loggingService
119 */
120 public function injectLoggingService(Tx_Foo_Service_LoggingService $loggingService) {
121 $this->loggingService = $loggingService;
122 }
123 }
125 The DI container finds that the class "MyController" has an method whose name starts with "inject",
126 and thus passes the logging service to MyController.
127 It is important that you can *only retrieve Singletons* through the inject annotations. If you need
128 to instanciate a prototype object, it is important to *not* use t3lib_div::makeInstance() anymore
129 (as it bypasses the DI container), but instead you need to inject the ObjectManager, and ask it
130 to create your prototype object using the create() method. Example:
132 class Tx_Foo_Controller_MyController {
133 protected $logFile;
135 /**
136 * @param Tx_Extbase_Object_ObjectManagerInterface $objectManager
137 */
138 public function injectObjectManager(Tx_Extbase_Object_ObjectManagerInterface $objectManager) {
139 $this->logFile = $objectManager->create('Tx_Foo_Domain_Model_LogFile');
140 }
141 }
143 In the above example, you have seen that we reference not the concrete implementation *ObjectManager*,
144 but instead the *ObjectManagerInterface*. If a name ends with "...Interface", Extbase DI automatically
145 strips away the "Interface" from the name, and expects to find a concrete implementation of that interface.
146 This is generally a very good practice: For your core classes, you should always reference an *interface*,
147 and let the DI container instanciate the concrete class.
149 Additionally, Extbase DI allows to *replace* certain implementation classes by other classes through
150 configuration in TypoScript. Let's give an example, and then you can see the concept:
152 config.tx_extbase.objects {
153 Tx_Extbase_Persistence_Storage_BackendInterface {
154 className = Tx_Extbase_Persistence_Storage_Typo3DbBackend
155 }
156 }
158 This essentially means to the DI container: "At all places where you encounter a "BackendInterface",
159 you should instanciate the "Typo3DbBackend" class."
161 However, note that this setting can only be configured *globally* right now, it is not possible
162 to override that on a per-extension basis.
164 Generally, the Extbase DI container provides a subset of the functionality of FLOW3's dependency injection.
166 Dispatcher Refactoring & Completely re-done Configuration Manager
167 -----------------------------------------------------------------
169 In the last versions of Extbase, the Dispatcher (Tx_Extbase_Dispatcher) was the main entry point to Extbase.
170 However, as we did not have Dependency Injection at that point, it became really complex and did lots of things
171 which it should not do in the first place. That's why we greatly improved that part. Now, any Extbase extension
172 is invoked using the Tx_Extbase_Core_Bootstrap. Additionally, the TypoScript used for the registration of any
173 Extbase extension has been cleaned up and adjusted:
175 lib.foo = USER
176 lib.foo {
177 userFunc = tx_extbase_core_bootstrap->run
178 extensionName = YourExtension
179 pluginName = YourPlugin
180 }
182 Additionally, you can also override the list of Switchable Controller Actions through TypoScript:
184 lib.foo = USER
185 lib.foo {
186 userFunc = tx_extbase_core_bootstrap->run
187 extensionName = YourExtension
188 pluginName = YourPlugin
189 switchableControllerActions {
190 Standard {
191 1 = action2
192 2 = action3
193 }
194 }
195 }
197 Of course, you cannot call actions which were not defined previously in the plugin; so the Switchable
198 Controller Actions in TypoScript can be only used to shrink the number of actions available.
200 NOTE: If you manually defined the above snippet, notice that there is a NON-BACKWARDS-COMPATIBLE change
201 in there. But you did that at your own risk, as that was never public API ;)
203 If you used Tx_Extbase_Dispatcher before in your own code, it should still work, but it is deprecated.
204 Instead, instead
206 OLD: Tx_Extbase_Dispatcher::getConfigurationManager()
207 NEW: inject Tx_Extbase_Configuration_ConfigurationManagerInterface into your class
209 OLD: Tx_Extbase_Dispatcher::getPersistenceManager()
210 NEW: inject Tx_Extbase_Persistence_ManagerInterface into your class
212 OLD: Tx_Extbase_Dispatcher::getExtbaseFrameworkConfiguration()
213 NEW: inject Tx_Extbase_Configuration_ConfigurationManagerInterface into your class,
214 and call $configurationManager->getConfiguration(Tx_Extbase_Configuration_ConfigurationManagerInterface::CONFIGURATION_TYPE_FRAMEWORK);
215 on the ConfigurationManager.
217 Please note that the Configuration Manager is STILL NO PUBLIC API, and its method signature has also changed.
219 QueryResult refactoring (needed for Fluid Widgets)
220 --------------------------------------------------
222 Before this change, a call of $query->execute() inside a repository immediately executed the query and
223 returned the result as array.
224 Now, queries are executed lazily at the first moment where you really need them. This means that $query->execute()
225 returns an object of type Tx_Extbase_Persistence_QueryResultInterface, which behaves like an array, meaning you
226 can use foreach() to loop over the query result.
227 However, due to an inconsistency of PHP, the array_* methods, and the iteration methods like current(),
228 next(), ... do NOT work on objects which implement ArrayAccess -- that's the reason why the QueryResult
229 refactoring is a breaking change.
231 Now, however, the following is possible:
232 * Return the first query result: $query->execute()->getFirst()
233 * Get the underlying query: $query->execute()->getQuery()
234 * Convert the result to array: $query->execute()->toArray()
236 This change is a prerequisite for Fluid Widgets to work. See the Fluid ChangeLog for details.
239 Configurable Plugin Namespaces
240 ------------------------------
242 By default each Extbase plugin has a unique URI prefix to avoid collisions with other plugins on your website.
243 This so called plugin namespace usually has the format tx_yourextension_yourplugin.
244 With Extbase 1.3 it is possible to override this namespace. This comes in handy if want to interact with 3rd party
245 extensions, for example with tt_news:
247 plugin.tx_yourextension.view.pluginNamespace = tx_ttnews
249 This sets the plugin namespace of all your plugins inside the extension to "tx_ttnews", making it possibl
250 to directly access tt_news parameters in your controller:
252 /**
253 * @param integer $tt_news tt_news Article uid
254 * @return void
255 */
256 public function yourAction($tt_news) {
257 // interact with $tt_news uid
258 }
260 This works with automatic mapping to Domain models too of course:
262 /**
263 * @param Tx_YourExtension_Domain_Model_NewsArticle $tt_news tt_news Article
264 * @return void
265 */
266 public function yourAction(Tx_YourExtension_Domain_Model_NewsArticle $tt_news) {
267 // interact with $tt_news object
268 }
270 You can also override the plugin namespace for a single instance by adding the section <view.pluginNamespace> to your
271 plugin FlexForm.
274 Automatic target page determination
275 -----------------------------------
277 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
278 the need to specify target pages from within your Extension. Of course you can put all your functionality into one fully
279 fledged plugin, then you won't have to deal with target pages as the current page is used by default.
281 But sometimes you want to be able to change the surrounding contents of a special view of your extension (e.g. the
282 subcontent column of a details page). As before you can still specify the target page explicitly like:
284 <f:link.action action="foo" pageUid="123" />
286 With Extbase 1.3 you can also use a new feature called "automatic target page determination". It is disabled by default,
287 but you can enable it with the following TypoScript:
289 plugin.tx_yourextension.view.defaultPid = auto
291 Then Extbase will search the page tree for a plugin that is configured to handle the specified action and you can omit
292 the "pageUid" parameter in your links. Of course, this does not work if you use the same plugin multiple times in your
293 page tree. In this case you can override the default page ID for the respective plugins:
295 plugin.tx_yourextension_yourplugin.view.defaultPid = 123
297 Note: By default this feature is not activated, because that would be a breaking change in some cases
300 Improved resolveView() mechanism
301 --------------------------------
303 Another feature we backported from FLOW3 is the improved view resolving.
304 You can now change the default view implementation *per format* by inserting the following line in your Controller:
306 protected $viewFormatToObjectNameMap = array(
307 'json' => 'Tx_YourExtension_View_JsonView',
308 'html' => 'Tx_YourExtension_View_HtmlView'
309 );
312 Allowing plugins to be registered as new content element
313 --------------------------------------------------------
315 This is done using an additional parameter to Tx_Extbase_Utility_Extension::configurePlugin
316 that allows you to specify the plugin type. Example:
318 Tx_Extbase_Utility_Extension::configurePlugin(
319 $_EXTKEY,
320 'BlogList',
321 array('Blog' => 'index'),
322 array(),
323 Tx_Extbase_Utility_Extension::PLUGIN_TYPE_CONTENT_ELEMENT
324 );
325 (The default value for the pluginType parameter is Tx_Extbase_Utility_Extension::PLUGIN_TYPE_PLUGIN)
327 Default Orderings & QuerySettings
328 ---------------------------------
330 It is now possible to change the default orderings of a repository without you having to modify the query by setting
331 the $defaultOrderings property of your Repository to a non-empty array:
333 protected $defaultOrderings = array(
334 'title' => Tx_Extbase_Persistence_QueryInterface::ORDER_ASCENDING,
335 'date' => 'title' => Tx_Extbase_Persistence_QueryInterface::ORDER_DESCENDING
336 );
338 This will change the default ordering for all queries created by this repository. Of course you can override the
339 ordering by calling $query->setOrderings() in your custom finder method.
341 Besides it's now possible to change the default query settings of a repository. This way you could for instance disable
342 "respect storage pid" for all queries. We added a life-cycle method "initializeObject" to the repository which will be
343 executed as soon as the repository is created. Just override it like the following:
345 public function initializeObject() {
346 $querySettings = $this->objectManager->create('Tx_Extbase_Persistence_Typo3QuerySettings');
347 $querySettings->setRespectStoragePage(FALSE);
348 $this->setDefaultQuerySettings($querySettings);
349 }
351 Of course, QuerySettings can be overridden too in your custom finder method by calling $query->setQuerySettings();
354 Full Changes for 1.3.0 Beta 1a:
355 ===============================
356 [+TASK] Extbase: Re-implement support for BE modules
357 [+FEATURE] Extbase (Utility): Allow plugins to be registered as new content element
358 Added a fifth parameter to Tx_Extbase_Utility_Extension::configurePlugin that allows
359 you to specify the plugin type (currently "list_type" and "CType" are supported).
360 Thanks to Marc Bastian Heinrichs, Rens Admiraal & Franz Koch for your help!
361 Resolves: #10666
362 [+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
363 [!!!][~TASK] Extbase (Configuration): Major rework of the ConfigurationManager
364 Configuration of controllers and actions is now stored in a global registry
365 ($GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['extbase']['extensions']). But you
366 should never access this directly. Instead always retrieve the frameworkConfiguration
367 from the ConfigurationManager.
368 Inserting an Extbase plugin is now as simple as:
369 lib.foo = USER
370 lib.foo {
371 userFunc = tx_extbase_core_bootstrap->run
372 extensionName = YourExtension
373 pluginName = YourPlugin
374 }
375 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().
376 NOTE: Unit tests of Extbase and Fluid v4 are broken currently. We'll be fixing those asap
377 [~TAKS] Extbase (MVC): FrontendRequestHandler now retrieves the current cObject through the ConfigurationManager
378 [+BUGFIX] Extbase (MVC): FrontendRequestHandler was refering to $this->frameworkConfiguration which wasn't available
379 [-API] Extbase (MVC): marked Tx_Extbase_MVC_Web_Request::getContentObjectData() deprecated as should retrieve the current cObject through the ConfigurationManager
380 [+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
381 [+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)
382 [~TASK] Extbase (Core): The Flashmessages now get persisted in the Bootstrap in resetSingletons()
383 [-TASK] Extbase (Core): Removed some commented lines from Bootstrap
384 [FEATURE] Extbase (Object): Make DI Class Mapping configurable through TS
385 It is now possible to configure the Dependency Injection class mapping by specifying:
386 config.tx_extbase.objects.[FullyQualifiedObjectName].className = [NewClassName]
387 This has the effect of effectively replacing [FullyQualifiedObjectName] with
388 [NewClassName].
389 Resolves: #10559
390 [-TASK] Extbase (Utility): Removed two obsolete checks for $GLOBALS['TSFE']->tmpl->setup['tt_content.']['list.']['20.'] in Tx_Extbase_Utility_Extension
391 [~TASK] Extbase: added two doc comments that were missing
392 [+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
393 [+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())
394 [+BUGFIX] Extbase (Persistence): Replaced two occurrences of Query->count() by Query->execute()->count() to avoid deprecated warnings in the Core
395 [+BUGFIX] Extbase (MVC): view configuration (templateRootPath, ...) has to be set before View::canRender() is called
396 [!!!][+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.
397 [+BUGFIX] Extbase (Reflection): ReflectionService now uses a cacheIdentifier per Extension. Besides the Bootstrap now resets the ReflectionService after dispatching a request. This resolves #10146
398 [+TASK] Extbase (Configuration): The ConfigurationManager now holds the current cObject. You can retrieve it via ConfigurationManagerInterface::getContentObject()
399 [+BUGFIX] Extbase (Configuration): When loading configuration of other plugins, the context specific configuration (e.g. flexform settings) are no longer merged with the frameworkConfiguration
400 [+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
401 [+TASK] Extbase (Persistence): QuerySettings now also store the storage page id(s). This is required for the upcoming Ajax Widgets
402 [+BUGFIX] Extbase: fixed php warning in Tx_Extbase_Persistence_LazyLoadingProxy when loading the real instance would return NULL. Resolves #10683
403 [+BUGFIX] Extbase: use 3rd parameter = TRUE of t3lib_div::trimExplode to split switchableControllerActionParts from flexform. Thanks to Georg Ringer. Resolves #10688
404 [+TASK] Extbase: Replaced "public static" by "static public" in various places to be CGL conform
405 [+TASK] Extbase: Marked Utitlity_Extension camelCase/underscore helper functions deprecated
406 [+TASK] Extbase: Removed obsolete FIXME comments, whitespace fixes
407 [!!!] Extbase: Reintegrating branch "dispatcher" to trunk. Resolves: #10605
408 Branch history:
409 [+FEATURE] Extbase (Configuration): Extend ConfigurationManager so that it can load configuration of different plugins
410 [+FEATURE] Extbase (Configuration): 1st level cache for ConfigurationManager. Resolves: #10717. Resolves: #10716
411 [+TASK] Extbase: cleaned up Configuration* implementation, replaced t3lib_div::makeInstance() calls
412 Streamlined ConfigurationManager API and enforced its usage throughout the Extbase classes.
413 Replaced all t3lib_div::makeInstance() calls by $objectManager->create()/$objectManager->get() throughout the Extbase classes.
414 Some smaller tweaks and fixes. Resolves: #10655. Resolves: #10712
415 [TASK] Extbase (Object): Make tests work again. Resolves: #10709
416 [TASK] Extbase (Object): Updated autoload.php and emconf. Relates to: #10561
417 [TASK] Extbase (Object): Use typed exceptions. Relates to: #10561
418 [TASK] Extbase (Object): CGL cleanup
419 Additionally, removed support for @inject annotations at methods. Relates to: #10561
420 [TASK] Extbase (Object): Remove getParents. Relates to: #10561
421 [TASK] Extbase (Object): Remove isSingleton. Relates to: #10561
422 [TASK] Extbase (Object): Remove injectExtensionSettings feature. Relates to: #10561
423 [TASK] Extbase (Object): Change namespaces to Tx_Extbase_Object_Container. Relates to: #10561
424 [TASK] Extbase (Object): Add Container to Extbase. Relates to: #10561
425 [+TASK] Extbase (Core): moved Tx_Extbase_Bootstrap to Tx_Extbase_Core_Bootstrap
426 Moving Bootstrap to be compliant with FLOW3
427 Removed obsolete Classes. Resolves: #10704
428 [+TASK] Extbase: Merged current trunk (r2689) with local modifications into dispatcher branch
429 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
430 [+TASK] Extbase (Configuration): Moved CONFIGURATION_TYPE_* constraints to ConfigurationManagerInterface. Resolves #10604.
431 [~TASK] Extbase (Configuration): The concrete configuration management strategy gets instanciate only once now.
432 [+FEATURE] Extbase (MVC): Decoupled framework settings from Dispatcher.
433 With the new dependency injection feature you can get the Configuration Manager injected by adding the lines
434 protected $configurationManager;
435 public function injectConfigurationManager(Tx_Extbase_Configuration_ConfigurationManagerInterface $configurationManager) {
436 $this->configurationManager = $configurationManager;
437 }
438 You can get various types of configuration invoking
439 $this->configurationManager->getConfiguration(Tx_Extbase_Configuration_ConfigurationManager::CONFIGURATION_TYPE_EXTBASE)
440 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.
441 [~TAKS] Extbase: Removed obsolete code.
442 [~TASK] Extbase: Added core patch for mod.php (see previous commit).
443 [+TASK] Extbase: Changed the way a module gets called.
444 - You can now specify a function name to be invoked by mod.php:
445 $TBE_MODULES['_dispatcher'][] = 'Tx_Extbase_Bootstrap->callModule';
446 - This requires a core patch.
447 [~TASK] Extbase: Changed configuration of the RequestHandler class names to TypoScript.
448 - The request handlers can now be registered in TypoScript with the setting:
449 config.tx_extbase.mvc.requestHandlers.[RequestHandlerClassName] = [RequestHandlerClassName].
450 - There are now two RequestHandlers in Extbase: FrontendRequestHandler and BackendRequestHandler. Common functionality is in the AbstractRequestHandler.
451 [+API][+FEATURE] Extbase (Utility): Implemented mechanism to register RequestHandlers.
452 [+TASK] Extbase: Backported Request Handler Resolver.
453 [~TASK] Extbase: Added "deprecated" annotation to Dispatcher.
454 [~TASK] Extbase: Added missing comment.
455 [+BUGFIX] Extbase (Reflection): The ReflectionService now gets injected to the dispatcher. Related to #10146.
456 [+BUGFIX] Extbase (Reflection): Changed the way the Reflection Service and it's cache gets initialized.
457 * Removed check for pre-initialized Reflection Service in the Bootstrap.
458 * Now using a fixed cache key ('ReflectionData').
459 Related to #10146.
460 [~TASK] Extbase: First step of the Dispatcher refactoring.
461 * Added and adapted some Unit Tests.
462 * Moved the Dispatcher to MVC.
463 * Added a backwards compatibility Dispatcher on root level.
464 * Added a Bootstrap class.
465 * Removed all backend module support for now.
466 Related to #7153.
467 [+TASK] Extbase: Added branch for the dispatcher refactoring.
468 [!!!][+BUGFIX] Extbase: fixed typo in getter and setter of Tx_Extbase_Domain_Model_FrontendUser::lastlogin . Thanks to Christian Schwan. Resolves #9345
469 [+FEATURE] Extbase (MVC): Backport possibility to change the view object class name more easily
470 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.
471 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
472 Resolves: #8990
473 [!!!][+FEATURE] Extbase (Persistence): Backport QueryResult from FLOW3
474 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).
475 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.
476 Resolves: #10566
477 [+BUGFIX] Extbase (Object): Minor fix in ObjectManager to make it compatible with PHP 5.2.x
478 Relates to: #9062
479 [+BUGFIX] Extbase (Object): Refactor Object Manager
480 The Object Manager is now at the same location and
481 has the same API as in FLOW3.
482 [+BUGFIX] Extbase: Major cleanups to Dependency Injection and Persistence
483 Now, DI finally works with Persistence, cleaning
484 this greatly up. Additionally, all internal
485 t3lib_div::makeInstance calls have been replaced.
486 Now, dependency injection is actually usable.
487 Additionally, we completely thought over which
488 persistence classes need to be singleton and which
489 should be prototype, leading finally to a
490 coherent design in the persistence layer.
491 [+BUGFIX] Extbase: remove non-used interfaces
492 Removed classes which were not used.
493 Relates to: #9062
494 Resolves: #10585
495 Resolves: #10564
496 * Cleaned up Persistence Backend
497 * Cleaned up QOM Factory
498 [+BUGFIX] Extbase (MVC): Fix arguments object
499 The arguments object is now correctly inheriting from ArrayObject
500 Resolves: #10562
501 [+BUGFIX] Extbase (MVC): Make database connection work again
502 Resolves: #10585
503 [+FEATURE] Extbase (DI): merging DI into trunk. (resolves #10558)
504 [+TASK] Extbase: Undefined identifier in Tx_Extbase_Persistence_Storage_Typo3DbBackend::removeRow
505 Method clearPageCache was given an undefined variable $uid as second parameter.
506 Resolves: #10570
507 [+TASK] Extbase: $query->contains generate incomplete SQL
508 Use FIND_IN_SET instead of a self-constructed query of LIKE statements
509 Resolves: #8959
510 [+BUGFIX] Extbase (Persistence): Removed method createQuery from the QOMFactory. It is neither part of the API nor is it used by Extbase. Resolves #10215
511 [+BUGFIX] Extbase (Property): Minor fix in PHP doc comment
512 Fix the order of @param annotation in Tx_Extbase_Property_Mapper::mapAndValidate()
513 Resolves: #5887
514 [~CONFIGURATION] Extbase (MVC): Changed default value for automatic target page determination
515 The page id gets automatically detected if plugin.tx_extensionname_pluginname.view.defaultPid
516 is an empty string (was "auto" before). This ensures backwards compatibility.
517 Resolves #9121
518 [TASK] Extbase: moved Release Notes to ChangeLog.txt.
519 [+FEATURE] Extbase (MVC): Automatic target page determination
520 you can use the "pageUid" argument of the link.* and uri.* view helpers
521 to link to a different page. That is deprecated though as we won't have
522 the notion of "page uids" in v5. Instead the target page is now determined
523 automatically.
524 If the target page can't be determined because more than one active
525 plugin is capable of handling the action an exception will be thrown.
526 In that case you'll have to define the target page either by using the
527 pageUid argument or - preferably - by setting
528 plugin.tx_extensionname_pluginname.view.defaultPid to a fixed page uid.
529 Note: This feature still has to be documented!
530 Resolves: #9121
531 [+FEATURE] Extbase (MVC): Configurable plugin namespace
532 until now the namespace (aka prefix) of Extbase plugins was
533 fixed (tx_extensionname_pluginname). This is now configurable
534 via TypoScript. Just write:
535 plugin.tx_extensionname_pluginname.view.pluginNamespace = my_custom_namespace
536 to change the prefix for a specific plugin or
537 plugin.tx_extensionname.view.pluginNamespace = my_custom_namespace
538 to change if for the whole extension.
539 Note: This feature still has to be documented!
540 Resolves: #8365
542 Changes for 1.3.0 Alpha 2:
543 ==========================
544 included in TYPO3 4.5.0 Alpha 2.
546 Since the last version, one (possible BREAKING) change happened:
548 * Fixed Extbase Caching Bug.
549 Non-cacheable actions were cached due to the fact that TYPO3s
550 TypoScript condition "GP" does not merge GET & POST vars.
551 Additionally "switchableControllerActions" that were overridden
552 in the plugin flexform were not taken into account.
554 !!! This is a breaking change if you set up your TS configuration
555 of the plugin manually.
557 Full Changes:
558 -------------
560 [!!!][+BUGFIX] Extbase: Fix Extbase Caching Bug (thanks to Bastian Waidelich)
562 [-TASK] Extbase (MVC): removed fallback to current page in AbstractController::redirect() as that's already done within the UriBuilder if $targetPageUid is NULL
565 Changes for 1.3.0 Alpha 1:
566 ==========================
567 included in TYPO3 4.5.0 Alpha 1.
569 Since the last version, the following notable things happened:
571 * 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.
572 * Performance improvements in TypoScript::convertTypoScriptArrayToPlainArray. Thanks to Timo Schmidt.
573 * Numerous other bugfixes, see below.
575 Full Changes:
576 -------------
577 [~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.
578 [+TASK] Extbase (MVC): cleaned up View implementations and added assign() and assignMultiple() methods to ViewInterface. This resolves #9137
579 [+BUGFIX] Extbase: Fixed a small typo in extension description.
580 [+BUGFIX] Extbase (Persistence): DataMapper now mapps NULL into a property on non-existing related object instead of FALSE. Resolves #8973.
581 [+BUGFIX] Extbase (Reflection): getParentClass() in Tx_Extbase_Reflection_ClassReflection no longer causes a fatal error if no parent class exists. Resolves #8800.
582 [+BUGFIX] Extbase (Utility): Improved performance of TypoScript::convertTypoScriptArrayToPlainArray. Thanks to Timo Schmidt. Resolves #8857.
583 [~TASK] Extbase: Changed state to 'stable'. Resolves #8768.
584 [+BUGFIX] Extbase: Fixed EOL and encoding of several files. Resolves #8876.
585 [+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.
586 [!!!][+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.
587 [+BUGFIX] Extbase (Persistence): Fixed a problem where localized objects inside an aggregate are not translated. Resolves #8555.
588 [~TASK] Extbase: Removed new lines at the end of php files.
590 RELEASE NOTES of Extbase v1.0.0
591 ===============================
593 This package contains the Extbase Framework for Extensions. You may
594 also want to install the BlogExample (blog_example) to experiment
595 with. This little example extension demonstrates some of the main
596 features of Extbase. The documentation is bundled in a separate
597 extension called doc_extbase. Both, the blog_example and the
598 doc_extbase can downloaded via TER.
600 http://typo3.org/extensions/repository/view/blog_example/current/
601 http://typo3.org/extensions/repository/view/doc_extbase/current/
603 Currently Extbase is in ALPHA state. Do not expect everything in the
604 right place and shape. And keep in mind that the API may change
605 until TYPO3 v4.3beta1 is released.
607 If you have any feature requests or encountered issues regarding
608 this package please use the facilities on forge to report.
610 We are very open to answer your questions. Please use the newsgroup
612 typo3.projects.typo3v4mvc on lists.netfielders.de
614 so other developers can react to your comments and also
615 profit from the postet solutions. Do not contact a member of the
616 development team via private email (or skype, or visits, or ...)
617 until he accepted this channel. We all do coding for Extbase on
618 our sparetime and must handle our regular work load - and don't
619 forget about our families ;-).
621 We hope you have fun with this package!
623 -- Your Extbase Development Team
626 ===========================
627 git log [startRevision]..HEAD --pretty=format:"%s%n%b%n" | grep -v "^$" | grep -v "git-svn-id"
629 Verify that the merge into the Core succeeded:
630 diff -urNw --exclude=".git" --exclude=".svn" -I "@version" ../../../typo3/sysext/extbase/ .