forked from agavi/agavi
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathRELEASE_NOTES
69 lines (53 loc) · 7.36 KB
/
RELEASE_NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
AGAVI RELEASE NOTES
===================
Version 1.1.0 - August ??, 2009
===============================
Configuration
-------------
All configuration namespaces have been bumped to version 1.1 as a consequence of a version bump in the global "envelope" namespace, which now allows "xml:space" and "ae:literalize" attributes on the <parameter> element to control whitespace trimming and literalizing (conversion of booleans, expansion of configuration directives). Several configuration file namespaces contain new elements or changed behavior as detailed below. The UPGRADING file lists all changes and their implications. New XSL transformations will automatically convert older configuration files to new namespaces and adjust behavior where applicable, allowing you to run your projects with Agavi 1.1 without having to adjust configuration files immediately.
Response
--------
Response classes now extend from AgaviAttributeHolder instead of AgaviParameterHolder. Attributes from each namespace are merged over individually, in the same way as HTTP headers, cookies and other metadata - info from the "child" response does not overwrite info on the response the data is merged to ("parent"). If however the attribute already exists in the parent, and both parent and child value are an array, then those values are merged. In this case, for identical keys, the value from the child array does not overwrite the value from the parent array. Numeric keys, however get appended. You can use this functionality to, for instance, implement caching of metadata such as CSS and JavaScript files to be loaded in the Master template - something that is not possible with global response attribute once you start using such functionality in slots - caching the response attributes would mean corrupt data with slots re-used on different pages.
Routing
-------
AgaviHttpRedirectRoutingCallback allows redirects of matched routes to static URLs or to other routes, including the ability to perform basic rewriting of arguments. The associated ticket #1382 contains further details.
Slots
-----
You can now use array syntax for slot names. Setting slots "foo[0]" and "foo[1]" will result in $slots['foo'][0] and $slots['foo'][1].
Database
--------
Support for Propel versions prior to 1.3 has been dropped from AgaviPropelDatabase. AgaviCreoleDatabase has been removed.
Validators
----------
It is now possible to export request data arguments to a different source. This is done by either passing an AgaviValidationArgument object as the second argument to AgaviValidator::export(), or, if the validator does not provide an argument name or only a name, but not an object, via the "export_to_source" parameter of the validator.
Furthermore, a new third parameter in AgaviValidator::export() now accepts the result code to use when exporting; it defaults to AgaviValidator::SUCCESS and may be used to for instance require validation of the exported value by using AgaviValidator::NOT_PROCESSED.
The "provides" and "depends" options of a validator now take an sprintf() string where you can use position specifiers to access parts of the argument base.
This means that having a "provides" value of "foobar" with an argument base of "foo[]" will now provide into "foobar" for every iteration, and not into "foo[$key][foobar]" like in 1.0. To get this old behavior back in this example, you'd have to use "foo[%2$s][foobar]" or "%1$s[%2$s][foobar]" as the value for "provides". The referencing of argument base parts works exactly like in "export" strings.
For "depends", the exact same syntax and behavior is now used; the old behavior was for a plain "foobar" to depend on just "foobar" no matter the argument base, and for "[foobar]" with an argument base of "foo[]" to depend on "foo[$key][foobar]", which was a bit confusing and also meant that you could only ever depend on provides from the same argument base. To depend on the "provides" results for the same keys as in the example above, you would again use "foo[%2$s][foobar]" or "%1$s[%2$s][foobar]" (but if we assume that this second validator had "lulz[]" as the argument base, then only "foo[%2$s][foobar]" would work of course).
If your validation config is from the 1.0 namespace, then the old behavior is retained automatically, so if you want to take advantage of this new functionality, you must bump the config namespace to 1.1.
Some more examples can be found in ticket #1199 (and also in #1073 where the same syntax is discussed for the exporting feature).
Filters
-------
AgaviIFilter::executeOnce() has been deprecated; in most cases, you can simply use execute() instead, see UPGRADING for further information.
It is now possible to get the global filter chain as well as the filter chain of the current execution container (with the action filter chain) by calling AgaviController::getFilterChain() and AgaviExecutionContainer::getFilterChain(), respectively.
Filter chains now expose an interface to access individual filters by name via AgaviFilterChain::getFilter(); this allows filters to expose an API to adjust runtime behavior (e.g. for AgaviFormPopulationFilter as a more convenient alternative to request attributes). AgaviFilterChain::getType() now returns the type of the filter chain (AgaviFilterChain::TYPE_GLOBAL or AgaviFilterChain::TYPE_ACTION) so dual-use (global and action) filters can detect the calling context.
Autoloading
-----------
Agavi's autoloader has been moved to its own class and gained the ability to autoload namespaces. This functionality is compliant with the PSR-0 specification. The <autoload> element in namespace http://agavi.org/agavi/config/parts/autoload/1.1 now allows either a "class" attribute specifying a class name (in which case the element value is the path to the file containing that class) or a "namespace" attribute specifying a namespace prefix (in which case the element value is the path containing the files for that namespace). XSL transformations will transparently convert <autoload> elements with a "name" attribute from older namespaces to the latest version.
AgaviReturnArrayConfigHandler
-----------------------------
RACH is now an AgaviXmlConfigHandler and fully namespace aware. Transformations are automatically added in most cases for config files used with previous Agavi versions. Refer to UPGRADING for details.
AgaviSchematronProcessor and AgaviXslProcessor
----------------------------------------------
Both classes have been moved from config/util/ to util/ and decoupled from the configuration system; you can now use them in your application code to perform Schematron validation or XSL transformations.
XInclude Wildcards
------------------
The href attribute of <xi:include /> elements now supports glob() syntax with the GLOB_BRACE flag enabled, so you can do any of the following:
<xi:include href="%core.module_dir%/*/config/routing.xml" />
<xi:include href="%core.module_dir%/{Foo,Bar,Baz}/config/routing.xml" />
<xi:include href="%core.module_dir%/{WinningModule,*}/config/routing.xml" />
For any path matched, the <xi:include /> element will be duplicated with the expanded path inserted into the href attribute.
Duplicates are removed, so the "WinningModule" entry matched by the "*" wildcard alternative in the last example will not be included a second time.
Testing
-------
AgaviTesting::dispatch() now calls exit() with an appropriate shell exit code to indicate success or failures/errors by default; pass false as the second argument to prevent this behavior.