MINOR Fixed anchor markdown in upgrading guide, better formatting for config upgrade instructions

This commit is contained in:
Ingo Schommer 2012-04-30 17:50:05 +02:00
parent c2339d2181
commit 2784891bd4

View File

@ -15,7 +15,7 @@
## Upgrading ##
### sapphire renamed to framework [sapphire-rename] ###
### sapphire renamed to framework {#sapphire-rename}
`sapphire` has been renamed to `framework`.
@ -28,32 +28,31 @@ Here's a list of steps to check:
* Find and replace any references to `sapphire` in your custom code to `framework`. In your PHP code, you can use the constant `FRAMEWORK_DIR`,
which points to the framework directory, and in the templates you can use `$ModulePath(framework)`
### Object static functions replaced with new Config class [new-config] ###
### Object static functions replaced with new Config class {#new-config}
Static functions for getting a static variable on the `Object` class have been deprecated,
in favour of using the new `Config` class instead.
`Object::set_static('MyClass', 'myvar')` becomes `Config::inst()->update('MyClass', 'myvar', 'myval')` instead.
`Object::addStaticVars('MyClass', array('myvar' => 'myval'))` should be replaced with individual calls to `Config::inst()->update()` instead.
`Object::add_static_var('MyClass', 'myvar', 'myval')` becomes `Config::inst()->update('MyClass', 'myvar', 'myval')` instead.
`Object::set_uninherited('MyClass', 'myvar', 'myval')` becomes `Config::inst()->update('MyClass', 'myvar', 'myval')` instead.
* `Object::set_static('MyClass', 'myvar')` becomes `Config::inst()->update('MyClass', 'myvar', 'myval')` instead.
* `Object::addStaticVars('MyClass', array('myvar' => 'myval'))` should be replaced with individual calls to `Config::inst()->update()` instead.
* `Object::add_static_var('MyClass', 'myvar', 'myval')` becomes `Config::inst()->update('MyClass', 'myvar', 'myval')` instead.
* `Object::set_uninherited('MyClass', 'myvar', 'myval')` becomes `Config::inst()->update('MyClass', 'myvar', 'myval')` instead.
Any arrays you pass as values to `update()` will be automatically merged. To replace the variable, call `remove()` first, then call `update()`.
`Object::get_static('MyClass', 'myvar')` becomes `Config::inst()->get('MyClass', 'myvar', Config::FIRST_SET)`
`Object::uninherited_static('MyClass', 'myvar')` becomes `Config::inst()->get('MyClass', 'myvar', Config::UNINHERITED)`
`Object::combined_static('MyClass', 'myvar')` becomes `Config::inst()->get('MyClass', 'myvar')` (no option as third argument)
* `Object::get_static('MyClass', 'myvar')` becomes `Config::inst()->get('MyClass', 'myvar', Config::FIRST_SET)`
* `Object::uninherited_static('MyClass', 'myvar')` becomes `Config::inst()->get('MyClass', 'myvar', Config::UNINHERITED)`
* `Object::combined_static('MyClass', 'myvar')` becomes `Config::inst()->get('MyClass', 'myvar')` (no option as third argument)
Note the different options for the third parameter of `get()`:
`Config::INHERITED` will only get the configuration set for the specific class, not any of it's parents.
`Config::FIRST_SET` will inherit configuration from parents, but stop on the first class that actually provides a value.
`Config::EXCLUDE_EXTRA_SOURCES` will not use additional static sources (such as those defined on extensions)
* `Config::INHERITED` will only get the configuration set for the specific class, not any of it's parents.
* `Config::FIRST_SET` will inherit configuration from parents, but stop on the first class that actually provides a value.
* `Config::EXCLUDE_EXTRA_SOURCES` will not use additional static sources (such as those defined on extensions)
If you don't set an option, it will get all the values for the static, including inherited ones.
This was previously known as `Object::combined_static()`.
### DataExtension and deprecated extraStatics on extension classes [extensions] ###
### DataExtension and deprecated extraStatics on extension classes {#extensions}
`DataObjectDecorator` has been renamed to `DataExtension`. Any classes that extend `DataObjectDecorator`
should now extend `DataExtension` instead.
@ -101,7 +100,7 @@ Alternatively, you can define statics on the extension directly, like this:
'Title' => 'Varchar'
);
### New ORM: More flexible and expressive querying via `DataList` [new-orm-datalist] ###
### New ORM: More flexible and expressive querying via `DataList` {#new-orm-datalist}
The new "fluent" syntax to retrieve ORM records allows for a more
expressive notation (instead of unnamed arguments).
@ -144,7 +143,7 @@ for the presence of records, please call the count() method on the `DataList`:
See the ["datamodel" documentation](../../topics/datamodel) for more details.
### New ORM: Changes to manipulation of SQL queries [new-orm-sql-queries] ###
### New ORM: Changes to manipulation of SQL queries {#new-orm-sql-queries}
In the 2.4 ORM it was sometimes necessary to bypass the ORM for performance reasons. For example,
this command would have been intolerably slow:
@ -349,7 +348,7 @@ not when simply using the CMS or developing other CMS functionality.
If you want to extend the CMS stylesheets for your own projects without SCSS,
please create a new CSS file and link it into the CMS via `[api:LeftAndMain::require_css()]`.
### Built-in Javascript validation removed [js-validation] ###
### Built-in Javascript validation removed {#js-validation}
Built-in client-side form validation using `Validator.js` and `behaviour.js` has been removed, and is no longer supported.
Server-side validation remains. Developers are encouraged to use custom Javascript validation on their
@ -386,7 +385,7 @@ its no longer possible to set the following optional attributes via constructor
and `$folderName` (for `FileField` and `SimpleImageField`).
Please use the appropriate setters on the form field instance instead.
### EmailField now uses type "email" instead of type "text" [email-form-field] ###
### EmailField now uses type "email" instead of type "text" {#email-form-field}
EmailField now uses "email" for the `type` attribute, which integrates better with HTML5 features like
form validation in the browser.
@ -464,7 +463,7 @@ The new syntax supports injecting variables into the translation. For example:
:::php
_t('i18nTestModule.INJECTIONS2', "Hello {name} {greeting}", array("name"=>"Paul", "greeting"=>"good you are here"));
### Default translation source in YML instead of PHP $lang array, using Zend_Translate [zend-translate] ###
### Default translation source in YML instead of PHP $lang array, using Zend_Translate {#zend-translate}
This allows for a more flexible handling of translation sources in various formats.
Your own translations can be converted automatically via the ["i18n_yml_converter" module](https://github.com/chillu/i18n_yml_converter). Any modifications
@ -528,7 +527,7 @@ Breadcrumbs have been altered to be their own template. In the process of this,
SiteTree::$breadcrumbs_delimiter has been removed. To customise breadcrumbs now, create a template
BreadcrumbsTemplate.ss from cms/template to your theme or application.
### Deprecation API [deprecation] ###
### Deprecation API {#deprecation}
There is a new deprecation API that generates deprecation notices. Calls to Deprecated methods
will only produce errors if the API was deprecated in the release equal to or earlier than the