Typed this up at Programmers.SE first, but imagine this may be better suited to here - purely because it's not asking for a advice regarding a specific technical issue. Feel free to vote to move though!
I'm currently working on a project using the "Spree" e-commerce platform for Ruby on Rails. It's been a complete joy to configure and to work with. The joy stopped there though.
I'm trying to develop a completely custom interface - one that bears no similarity at all with the default configuration. Now the Spree documentation suggests I have only two options:
deface overrides. Everywhere. Seemingly to override other overrides.Naturally, for such a dramatic change in style using deface is a complete nightmare; Deface does not look like an acceptable way to be expected to re-write a complete UI in; nor does it seem very efficient. So I opted to completely rebuild the views.
Then the realisation hits that there are around 8 plugins all relying on deface overrides, with the view files hardcoded and the target selectors often being 'flakey' (at best).
Apart from the very minimal documentation on the spree website, all I can find are slideshows from various conferences, which - without the context of the talk are actually of minimal use. They all seem to focus on using deface overrides for largely simplistic changes, and the more recent ones appear to be over a year old.
Am I missing something? Does anyone know of the best practice for performing something like this? Where I should actually be looking?
I have gone through the same problem and as you suggested, when there are lot of plugins using deface, it is better to use deface rather than overriding the entire view. It took some time to learn the fact that mecca of spree and the guide apart from documentation is the github sourcecode for spree. Anything missing in the documentation is present here.
If you want to override a view, there are two ways:
1) You want to override it completely using a new view. In such case, I would recommend not to change its existing structure used in the present source code and add your new changes. This way you are still making the data hooks available to other plugins depending on deface which depends on your view's html code structure and tags.
2) Using Deface. TO get started with Deface is a bit if a nightmare as there aren't sufficient documentations. The best way to get started using Deface is github.
The most important utility to test your new view code after Deface has replaced is to use rake tasks.
To see the elements selected with a tag use:
rake deface:test_selector['spree/address/_form','p'] - This shows all elements using p in the corresponding view partial.
To see the original partial use:
rake deface:get_result[shared/_head]
These are mentioned at deface's github but these come very handy, hence emphasizing.