| 1 | AGAVI UPGRADING INSTRUCTIONS |
|---|
| 2 | ============================ |
|---|
| 3 | |
|---|
| 4 | Upgrading to 1.0 Series from 0.11 Series |
|---|
| 5 | ======================================== |
|---|
| 6 | |
|---|
| 7 | Upgrading to Agavi 1.0 requires very little effort as the API remained identical. |
|---|
| 8 | |
|---|
| 9 | It is recommended that you refer to the RELEASE_NOTES to see a list of deprecated elements, and change your application accordingly. |
|---|
| 10 | |
|---|
| 11 | However, a couple of changes might affect your application: |
|---|
| 12 | |
|---|
| 13 | Configuration file XML namespace changes |
|---|
| 14 | ---------------------------------------- |
|---|
| 15 | Legacy support for configuration files with no namespace (from 0.11 unstable versions) has been dropped. |
|---|
| 16 | That means <configurations> without xmlns="http://agavi.org/agavi/1.0/config" as the namespace will not work anymore. |
|---|
| 17 | |
|---|
| 18 | New namespaces for all configuration files have been introduced, and envelope namespaces and actual content namespaces are now separate: |
|---|
| 19 | <a:configurations xmlns:a="http://agavi.org/agavi/config/global/envelope/1.0"> |
|---|
| 20 | <a:configuration> |
|---|
| 21 | <handlers xmlns="http://agavi.org/agavi/config/parts/config_handlers/1.0"> |
|---|
| 22 | <handler pattern="%core.config_dir%/autoload.xml" class="AgaviAutoloadConfigHandler"> |
|---|
| 23 | <a:parameter name="foo">bar</a:parameter> |
|---|
| 24 | </handler> |
|---|
| 25 | </handlers> |
|---|
| 26 | </a:configuration> |
|---|
| 27 | </a:configurations> |
|---|
| 28 | |
|---|
| 29 | Please refer to the documentation for a full list of configuration namespaces and their roles. |
|---|
| 30 | |
|---|
| 31 | Template layer output availability |
|---|
| 32 | ---------------------------------- |
|---|
| 33 | By default, the output of the previous template layer is only available in $inner, not anymore through $slots['layername']. This can be changed through a configuration setting for the execution filter, but is strongly discouraged, as $inner is more portable (and also more logical). |
|---|
| 34 | |
|---|
| 35 | Previously Deprecated Elements that have been removed |
|---|
| 36 | ----------------------------------------------------- |
|---|
| 37 | The following methods and attributes were deprecated in Agavi 0.11 and have been removed in this following release: |
|---|
| 38 | |
|---|
| 39 | - AgaviRequest::getActionAccessor(), use AgaviRequest::getParameter('action_accessor') |
|---|
| 40 | - AgaviRequest::getModuleAccessor(), use AgaviRequest::getParameter('module_accessor') |
|---|
| 41 | - AgaviTranslationManager::getClosestMatchingLocale(), superseded by AgaviTranslationManager::getLocaleIdentifier() |
|---|
| 42 | - AgaviTranslationManager::getLocaleFromIdentifier(), superseded by AgaviTranslationManager::getLocale() |
|---|
| 43 | - request attribute "matchedRoutes" in namespace "org.agavi.routing" is now called "matched_routes" to go with the general convention |
|---|
| 44 | |
|---|
| 45 | Behavior changes resulting from bug fixes |
|---|
| 46 | ----------------------------------------- |
|---|
| 47 | Some bugfixes resulted in minor behavioral changes and might require that you perform minor updates to your code: |
|---|
| 48 | |
|---|
| 49 | - The Security Filter now always runs if "core.use_security" is enabled and per- |
|---|
| 50 | forms the Action::isSecure() check itself. |
|---|
| 51 | |
|---|
| 52 | Previous behavior: |
|---|
| 53 | This was previously done in the Execution Container, where the Security |
|---|
| 54 | Filter was only added to the filter chain if the Action's isSecure() method |
|---|
| 55 | returned true. |
|---|
| 56 | |
|---|
| 57 | New behavior: |
|---|
| 58 | The Security Filter is now always run in the Action Fiter Chain, and no |
|---|
| 59 | check against Action::isSecure() is performed in the Execution Container. |
|---|
| 60 | Instead, the Security Filter is supposed to perform this check and act |
|---|
| 61 | accordingly. |
|---|
| 62 | The updated AgaviSecurityFilter instance does this by calling isSecure() on |
|---|
| 63 | the action instance before performing any other checks against credentials |
|---|
| 64 | or even authentication status, and will, if the method returns false, simply |
|---|
| 65 | continue in the Filter Chain and leave the execute() method afterwards. |
|---|
| 66 | |
|---|
| 67 | This affects you if: |
|---|
| 68 | - you have a custom Security Filter implementation or |
|---|
| 69 | - you subclassed AgaviSecurityFilter to perform additional checks. |
|---|
| 70 | |
|---|
| 71 | What you need to do: |
|---|
| 72 | - you need to add a check to see if the Action is flagged as secure, and if |
|---|
| 73 | not, continue in the Filter Chain and leave the filter afterwards. |
|---|
| 74 | |
|---|
| 75 | Steps to update your code: |
|---|
| 76 | - Open your custom Security Filter implementation. |
|---|
| 77 | - As far to the top in execute() as possible, but in any case before you are |
|---|
| 78 | making any checks against isAuthenticated() or even getCredentials(), |
|---|
| 79 | insert code that corresponds to the following snippet: |
|---|
| 80 | - Compare your change to the change made to Agavi's own Security Filter to |
|---|
| 81 | determine whether or not your new implementation is correct. The update |
|---|
| 82 | was made in trunk in revision 2267: |
|---|
| 83 | http://trac.agavi.org/changeset/2267#file1 |
|---|
