The URL to request the schema representation is the unique identifier.
We can't default to $request->getURL() since that's different for form submissions.
The schema.schema_url key is redundant, since the identifier is already contained on the top level 'id' key.
Keeping schema_url in a schema itself makes it less portable, particularly once we transition into
generic schemas which are not reliant on a particular record context (that's only contained in the schema_url)
This also fixes the issue of form schemas not refreshing after submit,
e.g. when form fields are added or removed.
Created a generic DataObject FormFactory interface that can be substituted in place of getCMSFields. Different FormFactories can depend on different kinds of context, such as
'Record' or 'Controller' - it's the responsibility of the code calling the factory to interpret and
supply this context.
The expected use-case is that rather than overriding getCMSFields(), developers can
change CMS UIs by manipulating the FormFactory associated with the given DataObject.
This is an experimental UI and may change before 4.0 stable is released.
API Remove DataObject::validateModelDefinitions, and move to DataObjectSchema
API Remove deprecated 3.0 syntax for addSelect()
API made DataList::createDataObject public
API Move component parsing logic to DataObjectSchema
API Remove support for triangular has_many / belongs_many relationships
If you run tests outside of a composer autoloader-based environment, or
your autoloader isn’t pulling in Constants.php, everything will break.
This provides a more helpful error message.
This shifts the behat test run to be triggered form composer activity
within the framework module directly,
* silverstripe/serve is used to provide a webserver, based on the
php -S command
* se/selenium-server-standalone is used to install selenium rather than
a download command
Because we’re using serve, the behat configuration can be locked down.
Further refinements could be made on this:
* the behat-extension could be responsible for installing and
starting/stopping selenium, making these tests more portable
* xvfb initialisation could be provided with another bin tool in the
begat-extension: vendor/bin/xvfb 1024x768
* The bootstrap-file argument to serve could be provided as part of a
composer.json setting. This would make it easier for developers to
start a dev server simply by running vendor/bin/serve
* the behat-extension could be responsible for installing and
starting/stopping silverstripe/serve, removing the need for
specifying base_url at all, and possibly utilising the same bootstrap
file between serve and behat.
The SilverStripe project structure complicates the travis test run, and
the goal of this branch is to prevent it from being necessary.
- Unit tests can be run simply with PHPUnit.
- Behat test can be run with the silverstripe/serve module
Note that initially this commit doesn’t cater to the behat tests.
As part of this, we allow dev packages to be installed when testing
These settings don’t affect projects that use framework, only when
framework’s composer install / require calls are used themselves.
Since SS4 is pre-stable, these are important. They can probably be
removed once SS4 stable (and stable versions of support packages) have
been released.
Code was assuming that FRAMEWORK_DIR would always have a value. If it
doesn’t (because you’re running a test instance of a naked framework)
This caused URLs to be treated as root relative, which creates some
duplicate-inclusion bugs.
The use of ltrim() works, but is a bit clumsy. A more flexible approach
to including front-end assets of given modules would be preferable;
ideally something that also let you keep your code outside of the
web root.
The 'admin' module will be split off from 'framework',
where 'framework' only provides (mostly) frontend-agnostic PHP classes.
For example, HTMLEditorField.php has a TinyMCEConfig.php driver,
but doesn't come with its own JS includes.
They were used for TreeDropdownField JavaScript tests but were never run
on CI, hence have been a bit of a wasted effort.
We're using a different JS unit testing solution now (geared towards React),
and running Jasmine in parallel on Travis for a few test cases
doesn't warrant the setup effort involved.
The TreeDropdownField component will eventually move to a React solution
which can be developed in a test-driven fashion.
