Usage

Using Deface::Override - this is the traditional method whereby you define instances of the Deface::Override class directly.

Using the Deface DSL (.deface files) - the DSL provides a terser syntax, and better organization of the individual override files.

Both methods are interoperable, so you can use a mix, and redefine overrides defined one-way using the other.

Using Deface::Override

A new instance of the Deface::Override class is initialized for each customization you wish to define. When initializing a new override you must supply only one Target, Action & Source parameter and any number of Optional parameters.

Note: the source parameter is not required when the :remove, :set_attributes, :add_to_attributes, :remove_from_attributes actions are specified.

You should save your overrides in the app/overrides, normally one override per file using the same file name as specified in the :name argument. Deface will automatically require these from your application, and any engines installed.

Note: You should NOT manually require override files, as this can cause problems for precompiling.

Target

:virtual_path - The template / partial / layout where the override should take effect eg: "shared/_person", "admin/posts/new" this will apply to all controller actions that use the specified template.

Action

:remove - Removes all elements that match the supplied selector

:replace - Replaces all elements that match the supplied selector

:replace_contents - Replaces the contents of all elements that match the supplied selector

:insert_after - Inserts after all elements that match the supplied selector

:insert_before - Inserts before all elements that match the supplied selector

:insert_top - Inserts inside all elements that match the supplied selector, as the first child.

:insert_bottom - Inserts inside all elements that match the supplied selector, as the last child.

:set_attributes - Sets attributes on all elements that match the supplied selector, replacing existing attribute value if present or adding if not. Expects :attributes option to be passed.

:add_to_attributes - Appends value to attributes on all elements that match the supplied selector, adds attribute if not present. Expects :attributes option to be passed.

:remove_from_attributes - Removes value from attributes on all elements that match the supplied selector. Expects :attributes option to be passed.

Source

:text - String containing markup

:partial - Relative path to a partial

:template - Relative path to a template

:cut - Cuts (i.e. copies and removes) an element or a range of elements from the current template as the source, using css selector(s). Supports two versions:

selector - A single string css selector (first match is used).

{:start => 'selector_a', :end => 'selector_b'} - select a range of elements using :start and :end css selectors. The end element must be a sibling of the first/starting element.

:copy - Copies an element or a range of elements from the current template as the source, using css selector(s). Supports two versions:

selector - A single string css selector (first match is used).

{:start => 'selector_a', :end => 'selector_b'} - select a range of elements using :start and :end css selectors. The end element must be a sibling of the first/starting element.

Optional

:name - Unique name for override so it can be identified and modified later. This needs to be unique within the same :virtual_path

:disabled - When set to true the override will not be applied.

:original - Either a string containing the original markup that is being overridden, or a string that is the SHA1 digest of the original markup. If supplied Deface will log when the original markup changes, which helps highlight overrides that need attention when upgrading versions of the source application. Only really warranted for :replace overrides. NB: All whitespace is stripped before comparison. To generate the SHA1 digest do: Digest::SHA1.hexdigest(original_markup_string.gsub(/\s/, ''))

:closing_selector - A second css selector targeting an end element, allowing you to select a range of elements to apply an action against. The :closing_selector only supports the :replace, :remove and :replace_contents actions, and the end element must be a sibling of the first/starting element. Note the CSS general sibling selector (~) is used to match the first element after the opening selector (see below for an example).

:sequence - Used to order the application of an override for a specific virtual path, helpful when an override depends on another override being applied first, supports:

Scope

Deface scopes overrides by virtual_path (or partial / template file), that means all override names only need to be unique within that single file.

Redefining Overrides

You can redefine an existing override by simply declaring a new override with the same :virtual_path and :name that was originally used.
You do not need to resupply all the values originally used, just the ones you want to change:

So for example if the above override was defined in MyEngine it would be automatically named my_engine_add_link.
This can also be activated globally for all DSL overrides in your app's application.rb file:

config.deface.namespaced =true# default is false

Using the Deface DSL (.deface files)

Instead of defining Deface::Override instances directly, you can alternatively add .deface files to the app/overrides folder and Deface will automatically pick them up.
The path of each override should match the path of the view template you want to modify, say for example if you have a template at:

app/views/posts/_post.html.erb

Then you can override it by adding a .deface file at:

app/overrides/posts/_post/my_override.html.erb.deface

The format of a .deface file is a comment showing the action to be performed, followed by any markup that would be normally passed to the :erb, :text, :haml arguments:

<!-- insert_after 'h1' -->
<h2>These robots are awesome.</h2>

The same effect can also be achieved with haml, by changing the overrides filename to:

app/overrides/posts/_post/my_override.html.haml.deface

and including haml source:

/ insert_after 'h1'%h2 These robots are awesome.

Additional Options

You can include all the additional options you can normally use when defining a Deface::Override manually, a more complex example:

Disabled / Enabled

The DSL does not accept the instance style :disabled => boolean instead you can simply include either:

<!-- enabled -->

or

<!-- disabled -->

Namespacing

When using the DSL, overrides automatically take their name from the filename of the file in which they are defined
(ie my_override.html.erb.deface becomes my_override) so overrides with the same filename will replace each other,
even if they are defined in separate engines. If you want to avoid this, you can use the namespaced option :

<!-- insert_bottom 'head' namespaced-->

or activate it globally for all DSL overrides in your app's application.rb file:

config.deface.namespaced =true# default is false

Each override will then have its name namespaced to the engine in which it was defined
(ie my_override.html.erb.deface defined in MyEngine becomes my_engine_my_override),
allowing overrides in different engines with identical filenames to co-exist.

DSL usage for overrides that do not include markup

If your override does not require any markup, for example actions including :remove, :set_attributes, :remove_from_attributes, :add_to_attributes you can exclude the "html.erb" or "html.haml" from the file name and you do not need to wrap the arguments in a comment.

Rake Tasks

Deface includes a couple of rake tasks that can be helpful when defining or debugging overrides.

deface:get_result - Will list the original contents of a partial or template, the overrides that have been defined for a that file, and the resulting markup. get_result takes a single argument which is the virtual path of the template / partial:

deface:test_selector - Applies a given CSS selector against a partial or template and outputs the markup for each match (if any). test_selector requires two arguments, the first is the virtual_path for the partial / template, the second is the CSS selector to apply:

Production & Precompiling

Deface now supports precompiling where all overrides are loaded and applied to the original views and the resulting templates are then saved to your application's app/compiled_views directory. To precompile run:

DEFACE_ENABLED=true bundle exec rake deface:precompile

It's important to disable Deface once precompiling is used to prevent overrides getting applied twice. To disable add the following line to your application's production.rb file:

config.deface.enabled =ENV['DEFACE_ENABLED'] =='true'

NOTE: You can also use precompiling in development mode.

Adding to Capistrano

Adding the following to your deploy.rb will automatically compile the views during deploy

Deface overrides have full access to all variables accessible to the view being customized.

Caveats

Deface uses the amazing Nokogiri library (and in turn libxml) for parsing HTML / view files, in some circumstances either Deface's own pre-parser or libxml's will fail to correctly parse a template. You can avoid such issues by ensuring your templates contain valid HTML. Some other caveats include:

Ensure that your layout views include doctype, html, head and body tags in a single file, as Nokogiri will create such elements if it detects any of these tags have been incorrectly nested.

Parsing will fail and result in invalid output if ERB blocks are responsible for closing an HTML tag that was opened normally, i.e. don't do this: &lt;div <%= ">" %>

Gems or Spree Extensions that add overrides to your application will load them in the order they are added to your Gemfile.

Applying an override to a view that contains invalid markup (which, occasionally happens in Spree views) can break rendering that would normally pass a browser's own permissive rendering. This is because the nokogiri library takes it upon itself to correct the issue, which doesn't happen prior to applying deface. Sometimes that correction changes the rendering of the view in an unintended manner, appearing to break it. The easiest way to tell if this is the cause of an issue for you is to put your view into http://deface.heroku.com/ and diff the output with the html which rails renders without your override. If you see a difference in the structure of the html, you may have invalid markup in your view which nokogiri is correcting for you. See Spree issue #1789 for an example of what may be wrong in a view.