The classnames on the add-new button and breadcrumbs were not
translated due to the use of singular_name() instead of
i18n-singular_name() in GridFieldAddNewButton and GridFieldDetailForm.
In CMSBreadcrumbs.ss the (TopLevel)Controller is not recognized within
the Breadcrumbs loop, so the class that is used in css to style the
icon cannot be created. Moving the construction outside the loop will
remedy this. As far as I can see this works within the CMS.
- Removed redundant "module" relationship, has_one is already present in Student->Project relationship
- Simplified FirstName/LastName to Name on Student and Mentor models, makes for less sample code
- Removed detail views for Student and Mentor, as they don't add much educational value
- Fixed indentation in code examples
- Using GridField relation editor, listing students on relation instead of holder
- Added optional exercises for the readers
- Added conclusion, explaining when to use Page vs. DataObject
- Updated sample data to GSOC '12 rather than '07, anonymized and randomised a bit
- Thanks to Naomi Guyer for contributing!
The collector didn't find classes marked as entity providers
unless they were already loaded as a sideeffect of the preceding
execution path. Since we want to introspect the whole codebase,
autoloading is mandatory here.
Was inferred by the containing file previously,
which is deprecated behaviour, because it obscures
the fact that renaming an template file or copying
template code will change the context of the translations.
While it would be nice to use shorter and more readable namespaces,
this change would remove all existing translations.
Since there is no (easy) migration of entities to a new namespace,
having verbose template code is the lesser of two evils.
Automatic tree node updating fails when for example creating a new
translation, due to the update URL containing two question marks,
due to the locale get parameter.
Fixed by using the $.path.addSearchParams utility function, which properly
checks for existing query string parameters.
The augmentSQL DataExtension method is always extended on the base data
class of data objects in DataQuery::getFinilisedQuery(). This results
in augmentSQL not being called for extensions that are applied to non-
base data classes when finalizing the query.
For example, if Versioned was applied to class B which extends class A,
which in turn extends DataObject, then augmentSQL would be extended for
class A in DataQuery::getFinilisedQuery(). Since class A doesn't have
the Versioned extension in this example, it would not work for class B.
Fixed this by extending augmentSQL on the actual data class and not
on the base class.
