YamlFixture
class YamlFixture (View source)
Uses Symfony's YAML component to parse a YAML document (see http://yaml.org).
YAML is a simple markup languages that uses tabs and colons instead of the more verbose XML tags, and because of this much better for developers creating files by hand.
The contents of the YAML file are broken into three levels:
- Top level: class names - Page and ErrorPage. This is the name of the dataobject class that should be created. The fact that ErrorPage is actually a subclass is irrelevant to the system populating the database. Each identifier you specify delimits a new database record. This means that every record needs to have an identifier, whether you use it or not.
- Third level: fields - each field for the record is listed as a 3rd level entry. In most cases, the field's raw content is provided. However, if you want to define a relationship, you can do so using "=>"
There are a couple of lines like this:
Parent: =>Page.aboutThis will tell the system to set the ParentID database field to the ID of the Page object with the identifier 'about'. This can be used on any has-one or many-many relationship. Note that we use the name of the relationship (Parent), and not the name of the database field (ParentID)
On many-many relationships, you should specify a comma separated list of values.
MyRelation: =>Class.inst1,=>Class.inst2,=>Class.inst3An crucial thing to note is that the YAML file specifies DataObjects, not database records. The database is populated by instantiating DataObject objects, setting the fields listed, and calling write(). This means that any onBeforeWrite() or default value logic will be executed as part of the test. This forms the basis of our testURLGeneration() test above.
For example, the URLSegment value of Page.staffduplicate is the same as the URLSegment value of Page.staff. When the fixture is set up, the URLSegment value of Page.staffduplicate will actually be my-staff-2.
Finally, be aware that requireDefaultRecords() is not called by the database populator - so you will need to specify standard pages such as 404 and home in your YAML file.
Page:
home:
Title: Home
about:
Title: About Us
staff:
Title: Staff
URLSegment: my-staff
Parent: =>Page.about
staffduplicate:
Title: Staff
URLSegment: my-staff
Parent: =>Page.about
products:
Title: Products
ErrorPage:
404:
Title: Page not Found
ErrorCode: 404Traits
A class that can be instantiated or replaced via DI
Properties
| protected | string | $fixtureFile | Absolute path to the .yml fixture file |
|
| protected | string | $fixtureString | String containing fixture |
Methods
An implementation of the factory method, allows you to create an instance of a class
Creates a class instance by the "singleton" design pattern.
Persists the YAML data in a FixtureFactory, which in turn saves them into the database.
Details
static Injectable
create(mixed ...$args)
An implementation of the factory method, allows you to create an instance of a class
This method will defer class substitution to the Injector API, which can be customised via the Config API to declare substitution classes.
This can be called in one of two ways - either calling via the class directly, or calling on Object and passing the class name as the first parameter. The following are equivalent: $list = DataList::create(SiteTree::class); $list = SiteTree::get();
static Injectable
singleton(string $class = null)
Creates a class instance by the "singleton" design pattern.
It will always return the same instance for this class, which can be used for performance reasons and as a simple way to access instance methods which don't rely on instance data (e.g. the custom SilverStripe static handling).
__construct(string $fixture)
No description
string
getFixtureFile()
No description
string
getFixtureString()
No description
writeInto(FixtureFactory $factory)
Persists the YAML data in a FixtureFactory, which in turn saves them into the database.
Please use the passed in factory to access the fixtures afterwards.