yui.ymlEach component of the PlatformUI application is written as a YUI module. The YUI module system comes with a dependency=
system which is used in the PlatformUI application. For instance, the Plat=
formUI application has a module called ez-templatebasedview wh=
ich provides a base view class to ease the usage of a template. This module=
is a dependency of most of the views in the application and has itself som=
e dependencies, like for instance the view module from YUI. Those dependenc=
ies are expressed in the yui.yml configuration and this config=
uration is meant to be extended / overridden in other bundles. For instance=
:
system:
default:
yui:
modules: =20
ez-templatebasedview:
requires: ['ez-texthelper', 'ez-view', 'handlebars', 't=
emplate']
path: %ez_platformui.public_dir%/js/views/ez-templateba=
sedview.js
ez-loginformview:
requires: ['ez-templatebasedview', 'node-style', 'login=
formview-ez-template']
path: %ez_platformui.public_dir%/js/views/ez-loginformv=
iew.js=20
This configuration defines two modules =E2=80=93 ez-loginformview:
ez-templatebasedview requires the modules ez-texthel=
per, ez-view, handlebars and templat=
e. The source code of this module is in %ez_platformui.public_=
dir%/js/views/ez-templatebasedview.js on the disk;ez-loginformview requires the modules ez-templatebas=
edview, node-style and loginformview-ez-template<=
/code>. The source code of this module is in %ez_platformui.public_di=
r%/js/views/ez-loginformview.js on the disk.
Note that the order of module definitions is not important, ez-log=
informview can be defined before the ez-templatebaseview module even if the latter is a dependency of the former.
Most of the PlatformUI application views use a Handlebars template to ge=
nerate the HTML markup. In the application the templates are also handled a=
s YUI modules but those modules are special because they are dynamically ge=
nerated from the regular template files on the disk. For this to work, the =
YUI module corresponding to a template must have the type flag=
set to template. To complete the example above, the template =
module loginforview-ez-template should be defined in the follo=
wing way:
loginformview-ez-template:
type: 'template'
path: %ez_platformui.public_dir%/templates/loginform.hbt=20
css.y=
mlThe CSS files used by the application are also listed in css.yml, but in the case of CSS files, it's much simpler as this file just li=
sts the CSS files to load, example:
system:
default:
css:
files:
- '@eZPlatformUIBundle/Resources/public/css/views/field.css=
'
- '@eZPlatformUIBundle/Resources/public/css/views/fields/vi=
ew/relation.css'=20
To be able to extend the PlatformUI application configuration, the exten=
sion bundle has to set up its own configuration handling. For this, you onl=
y have to tweak the extension class generated in the bundle in the first step to load t=
he extension bundle's yui.yml and css.yml and to =
process their respective content with PlatformUI's configuration. The defau=
lt empty yui.yml and css.yml also have to be crea=
ted so that eZ Platform is still usable.
If you want to get more details on this operat= ion, you can read the Exposing SiteAccess-aware configuration f= or your bundle recipe.
After this, you just have to make sure the bundle has a Resources/=
public directory to install the assets with the following command:
$ app/console assets:install --symlink=20
The resulting code can be seen in the 2_configuration tag on GitHub (the intere=
sting part is the EzSystemsExtendingPlatformU=
IConferenceExtension class), this step result can also be=
viewed as a diff between tags 1_bundle and 2_configu=
ration.
After these two first steps, PlatformUI should remain perfectly usable a= nd unchanged. The next step is then to tweak the PlatformUI Application routin= g to start implementing the new feature.