tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-06-29 07:59:31 +02:00
Code Issues Projects Releases Wiki Activity

Docs for ownership API

Browse Source
This commit is contained in:
Aaron Carlino 2017-07-13 17:00:12 +12:00 committed by Daniel Hensby
parent 2b9369895d
commit dcb2424b05
No known key found for this signature in database
GPG Key ID: B00D1E9767F0B06E
1 changed files with 50 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
docs/en/04_Changelogs/4.0.0.md
View File

@ -152,15 +152,15 @@ public function countDuplicates($model, $fieldToCheck)
##### Class name remapping
If you've namespaced one of your custom page types then loaded up the CMS and see
a message telling you it's obsolete. This is likely because the `ClassName`
If you've namespaced one of your custom page types, you may notice a message in the CMS
telling you it's obsolete. This is likely because the `ClassName`
field in the `SiteTree` table still contains the singular model name, e.g. `BlogPost`
and that when you change it to `SilverStripe\Blog\Model\BlogPost` then everything
works again.
Luckily the `dev/build` task is configured to look for a legacy class name mapping
configuration setting and will update this for you automatically. For an example
take a look at `_config/legacy.yml` in the CMS module. For the Blog module we used
take a look at `_config/legacy.yml` in the CMS module. The Blog module, for instance, uses
this:
```yaml
@ -221,9 +221,9 @@ A better option is to replace it with `DataObject::getSchema()->tableName(BlogPo
The convention for naming controllers is now `[MyPageType]Controller`, where it used to be `[MyPageType]_Controller`. This change was made to be more compatible with the PSR-2 standards.
You can still use, for example, `Page_Controller`, but you will get a deprecation notice. Best to change it to `PageController` during your upgrade process.
You can still use, for example, `Page_Controller`, but you will get a deprecation notice. It is best to change it to `PageController` during your upgrade process.
By default, a controller for a page type *must* reside in the same namespace as its page. To break this convention, override `SiteTree::getControllerName()`.
By default, a controller for a page type *must* reside in the same namespace as its page. To use different logic, override `SiteTree::getControllerName()`.
#### Upgrade template locations and references
@ -244,8 +244,8 @@ the `SilverStripe\Forms` namespace.
#### Upgrade your member statics
If you've got some class configuration statics defined and they aren't private,
you may find that they don't register any more. For example, this code, taken from
If you have some class configuration statics defined and they aren't private,
you may find that they don't register anymore. For example, this code, taken from
the `silverstripe/tagfield` module will no longer work in SilverStripe 4.0.
```php
public static $allowed_actions = [
@ -272,7 +272,7 @@ private static $allowed_actions = [
While not critical to an upgrade, SilverStripe 4.0 has adopted the [PS-4 autoloading](http://www.php-fig.org/psr/psr-4/)
standard for the core modules, so it's probably a good idea to be consistent.
You can implement this into your composer configuration like so:
You can implement this in your composer configuration like so:
```js
...
@ -293,14 +293,15 @@ have also started to use `src/` as a default folder location instead of
`code/`. If you’re going to change, it's probably a good time to do it while you're
upgrading.
For examples, take a look at the file/folder structure compared to the
For examples, take a look at the file/folder structure and to the
`composer.json` configuration in either the `framework` or `cms` modules.
Please note that there are changes to template structure which in some cases
require templates to be in a folder location that matches the class's namespace
require templates to be in a folder location that matches the namespace of the class
that it belongs to, e.g. `themes/mytheme/templates/MyVendor/Foobar/Model/MyModel.ss`.
#### Get on board with PSR-# logging, too
One of the great changes that comes with SilverStripe 4 is the introduction of
[PSR-3](http://www.php-fig.org/psr/psr-3/) compatible logger interfaces. This
means we can use thirdparty services like Monolog.
@ -322,7 +323,7 @@ in this case!
##### Unit tests and PSR-3 loggers
If you've got some code that you've tested originally using `SS_Log`, and now moved
If you have some code that you've tested originally using `SS_Log`, and now moved
to using a Monolog Logger then you may notice occasions where your unit tests pass
but output a bunch of warnings, debug information, etc. to `stderr`. This is because
Monolog will use `stderr` as the default Handler unless you specify one.
@ -1317,10 +1318,45 @@ These methods are deprecated:
#### Implementation of ownership API
In order to support the recursive publishing of dataobjects, a new API has been developed to allow
developers to declare dependencies between objects. See the
[versioned documentation](/developer_guides/model/versioning) for more information.
developers to declare dependencies between objects. This is done to ensure that the published state
of linked components are consistent with their "owner." Without the concept of ownership, these linked
components could be implicitly exposed on the frontend, which may not align with the intent of the
content author.
By default all versioned dataobjects will automatically publish objects that they own.
For instance, on a products page which has a list of products, the products should not be published or
unpublished unless the products page is, too. The ownership API solves this by allowing you to declare
a two-way relationship between objects, typically, but not necessarily, linked by a database relationship
(`has_many`, `many_many`, etc.).
```php
class ProductPage extends Page {
private static $has_many = [
'Products' => Product::class
];
private static $owns = [
'Products'
];
}
class Product extends DataObject {
private static $extensions = [
Versioned::class
];
private static $has_one = [
'Parent' => ProductPage::class
];
}
```
If your objects are linked by something other than a database relationship, for instance, a custom
getter that is computed at runtime, the same rules can be applied, as long as you provide an `$owned_by`
setting on the child object.
For more information, see:
* The [DataObject ownership](https://docs.silverstripe.org/en/4/developer_guides/model/versioning/#dataobject-ownership) documentation
* The [versioned](/developer_guides/model/versioning) documentation
#### ChangeSet batch publishing