Themeing EVA views using custom templates [patch]

Entity Views Attachment lets you attach a view to a Drupal 7 entity. This means when viewing a node, you could display for example, a list of other nodes by the same author. See http://www.theweek.co.uk/columnist/michael-bywater

But due to the way the views plugin was written, it was not possible to use custom templates for EVA views. If you tried to, you would end up with a lot of 'underfined variable' notices for all the variables in your custom template.

E.g.
Notice: Undefined variable: title in include() (line 31 of /../sites/all/themes/../templates/eva-display-entity-view--gallery--entity-view-1.tpl.php).

There is a hard dependency on eva.theme.inc even when overriding eva-display-entity-view.tpl.php to a custom tpl. Due to this, template_preprocess_views_view() is not run.

The patch in http://drupal.org/node/1205008#comment-5130160 fixes the above limitation by removing the dependency from hook_views_plugins().

Managing optional features in a Drupal Distro

So you need to build a comprehensive distro using features to export data into code. Fair enough. What could be one of the most common problems in trying to create a common solution for all sites?

Problems:

1. 20% of the sites would want additional fields
   
   In your distro, say content type 'article' has 10 fields and needs 2 optional fields. All sites will use the 10 'core' fields and the 2 optional fields may or may not be used.
   
   
2. Some sites want to alter field labels and change display settings on content types

Solutions:

1. Separate overridable feature for extra fields per content type
   
   Export the main content with 10 fields into one feature and the optional fields into another feature. Site builders can leave the main feature alone and modify the extra feature only (change field permissions, usage, labels etc.)
   
   Perhaps its not easy to export the content type with the extra fields left out. In that case, manually remove the field's references from the export files. Usually those will be in *.features.field.inc & *.info files.
   
   Then export the extra fields in a separate content type and manually add a dependency to the main feature.
   
   
2. template_preprocess hooks.
   
   Consider encouraging site-builders to place all field alterations in appropriate hooks such as hook_form_alter() and hook_template_preprocess_page()
   
   
3. Override field display settings
   
   This module is still in its infancy but its possible to export field display settings separately into a feature. A comprehensive guide can be found here - http://www.agileapproach.com/blog-entry/new-paradigm-overriding-drupal-features
   

The thing about documentation

I love agile methodology and extreme programming. I used to work in a team that loved it and lived by its core philosophy. To top it of we had a strong technical manager who was a certified scrum master and new the approach inside out. Life was good.

Then our manager left. We got a lot of new recruits, many who had never worked in a core agile environment. Our teams got shaken up. Ultimately, the loudest voices got heard. 6 months into it, we have sort of become a mess. To sort of patch up the mess, somebody suggested documenting processes, because to some people, agile meant chaos. Of course agile methodology minimises documentation. Its not that we hate documentation. But I hate certain kinds of documentation. Documentation of processes.

How can you encapsulate all the nuances about human activities - interactive communicative and effective procedures - into words? Documenting processes is like making humans machines. Without creativity or without thought. Processes always are evolving and no two situations can be asked to follow the same text. People need to think on their feet each time. Agreed - some process documentation come with a disclaimer that these are just guidelines and to use proper judgement before following them. Now a poor new recruit new to the agile world would ask - where is that documented?

I believe in mentor-ship and process mentor-ship that encourages and teaches the ideology behind thought. Perhaps putting this ideology into text would not be bad since it does just that - captures ideology.

Anyway, I do like documentation on one important aspect - requirements. Although requirements may change in the real world, they still need to be documented. Because requirements need to be translated into code, which a machine needs to understand. Quite unlike process documentation which a human needs to understand, assimilate and generate an effective action out of.